'''“To invent an airplane is nothing. To build one is something. But to fly is everything.”''' ''—Otto Lilienthal''

== Overview ==

== Overview ==

Line 337:

Line 339:

[[Image:mongan1_airframe.jpg]]

[[Image:mongan1_airframe.jpg]]

−

=====Simulating a "Scenario"=====

+

=====Simulating a Scenario=====

−

Now we will create a video of an airframe in a simple scenario. I will start with the bd airframe, a Bubble Dancer RC model. The steps to create a video simulation are described in session2.txt.

+

Now we will create a video of an airframe in a simple scenario. I will start with the bd airframe, a Bubble Dancer RC model. The steps to create a video simulation are described in session2.txt. Once the aiframe is created, the masses applied and a run scenario created (provided in the .run file, although it could also be created within the AVL interface), it is simulated. We will simulate a 60 degree banked turn and determine the turn radius and speed needed to sustain that turn in a hallway.

+

+

The run case is executed as usual, but the simulation can be viewed by entering Eigenvalue mode (.MODE at the main menu). Typing "N B" we expand on the roots of the eigenvalue computation; at which point we can type X to examime a node, and select a root to enter playback mode. IXIX and IZIZ are used to set default inerta values on pitch and yaw before running the eigenvalue computation.

+

+

In this case, we see that the 60 degree bank can be maintained without loss of altitude. It is found that the bank be maintained at 8 meters per second (rather fast) with a bank radius of 4m. This is slightly outside the width of a hallway turn. Perhaps airspeed can be compromised. A slight descent is present in this simulation that will not be adequate for the hallway turn. The file is available here: [[Media:bd60_video.avi]].

+

+

The airframe data shows reasonable pitch up (13 degrees) and rudder control inputs are necessary to coordinate the turn. This airframe will likely satisfy the hallway turning requirement, as long as enough airspeed can be removed from the simulation without compromising a steady altitude. The data dump is availabhe here:

+

+

[[Image:bd60_pitchup.jpg]]

+

+

Using the OPER menu, then C1, the scenario can be edited and previewed without the video. That is, one can apply velocity and bank angle to determine the turning radius required. If the airspeed is too slow and a stall would result, the simulation fails with a bad alpha value. I tried a couple of scenarios that didn't quite cut it: I was aiming for a 4 meter turn radius with no more than .7meters/second loss in altitude, regardless of airspeed; though this isn't exactly realistic since we need to strap an engine on this thing that can sustain the speed. After a few trial and error sessions, I came up with a scenario that fit: an 80 degree bank (wow!) at 15 meters/second (about 33 mph). So realistically this glider doesn't won't do without some power behind it, but I've included the video to show it will work. I know empirically that I can't do much better, because there is little to no pitch up (theta) required to sustain the altitude in the turn. Any less speed and I'd be descending too much, any more and my turn radius would be lost.

+

+

[[Media:bd60_hallway.avi]]

+

+

On the other hand, my aircraft which was very, very light weight, took a few iterations before I got it right as well. For this aircraft, it was easier to get a small turning radius (3 feet), using a bank angle oscillating between 1 and 10 degrees (very light banking) at 2 feet per second of forward velocity. Slight pitch up through the turn is used to maintain altitude, which is kept constant through the turn. As bank angle decreases, so does pitch up, until the aircraft is actually slightly pitched down to avoid climbing from the excess airspeed. The video is shown here. Some reasons for improvement involve the very large wing, large aileron, and large rudder control surfaces. The elevator is also proportionally larger but this is of little consequence in this scenario. However, it should also be noted that these masses are considered rather lightweight, and this may or may not be realistic. But we will make that assumption for now, and see that the addition of that mass should be easily compensated for by extra bank or airspeed. There was plenty "left over" from this run, and that's a start.

+

+

[[Media:mongan_hallway.avi]]

== For Inspiration ==

== For Inspiration ==

Latest revision as of 13:52, 3 December 2006

“To invent an airplane is nothing. To build one is something. But to fly is everything.”—Otto Lilienthal

Overview

I don't know about the feasibility of such a project, but I think it would be interesting to model flight-capable "bio-inspired robots." I think this might exceed the limits of the Lego kit, anyway... :)

This would include a number of stages, including the modeling of birds (or "bird-inspired robots," if you will) in flight, as well as modeling simple autonomous flying machines (including gyrocopters, small airplanes/airfoils, and blimps). Perhaps even free gliders, balloon-based flight, etc., but these are not within the scope of the "bio-inspired" goals.

The target audience would be a K-12 environment, in which instructional goals would include exposure to the principles of aerodynamics and aeronautics, evolution of and differences among powered flight, and the history of human flight as inspired by nature.

I am also planning to be involved in the SeaPerch underwater robotics league with the Philadelphia School District. I think an underwater aspect to this project would be just as valuable to the target audience as a flight-aware one.

Just some thoughts...

Why?

In addition to the course and project goals, I have some other more personal objectives through this project. My goal is to expose the general public to the science and politics of aviation. How and why does it work, what are the misconceptions, and what makes it safe? It is the misconceptions of aviation that makes us "scared to fly."

For example, on a recent news broadcast (on a national broadcast station), it was stated that the NTSB was investigating the recent airplane accident in New York. The reporter said that he was told by the NTSB investigators that they were trying to determine how the airplane propeller was still turning at the time of the accident, despite evidence that the aircraft "went into a stall" -- thus 'causing the engine to stop' (as if on its own or due to some failure). I do not wish to speculate on the details of the accident, but instead simply on the misconception of the statement. In fact, a stall is an aerodynamic principle and has nothing to do with and has no impact on the engine or propeller. It is simply a disruption of airflow over the wings caused by an excessive angle of attack (brought about by a number of pilot-controllable things such as airspeed, excessive pitch-up attitude, or loaded weight). It is disappointing to me that people with misconceptions such as this are reporting to our decision-makers in Congress and in our big cities. The fast-track to sensible, rational decision making and public policy is education; it is my hope to inform those who are interested about something they might not learn from the news media.

To that end, I would recommend a couple of well-made movies that bring general aviation (GA) to the public at large. They are called "The Magic of Flight," a documentary about the history of aviation and the Blue Angels, in which they discuss the similarities of the development of flight with that of natural bird-flight; and "One Six Right," a documentary about GA and the Van Nuys Airport in California, the largest GA airport in the world.

The Bird

See "Flight Performance Characteristics of a Biologically-Inspired Morphing Aircraft" at http://mav.mae.ufl.edu/mujahid/publications/rsc04_nsc.pdf [1]. The goal, as [1] points out, is not to reproduce unmanned flight, but to produce an "organic flight vehicle." The understood primary mechanism is a morphing or "warped" wing, as opposed to the fixed or rotating wings we have in typical unmanned flight. Because fixed-wing unmanned flight was also bio-inspired, the same basic principles of airflow and fluid dynamics apply in each case. I invite you to read the FAA's "Pilot's Handbook of Aeronautical Knowledge" for information about these principles: http://www.faa.gov/library/manuals/aviation/pilot_handbook/. Nevertheless, it is interesting to observe the numerous fundamental differences between fixed-wing aircraft and birds. See the figure below from their paper, which features a common fixed-wing airfoil design, but modified to use a morphed wing powered by actuators:

[1] further points out something that we discussed briefly in class: namely, the need for dynamic aeroelastic analysis. It appears that only static aerodynamic analysis exists to date in such "highly-organic" warped-wing flight models. This is a possible area of research in this project and the primary focus of [1].

"This type of specialty in design is contrasted with winged aviators in the animal world. Birds employ gross
deformation in their configuration to achieve flight in vastly differing conditions. Whether by changing the position
of their wings or deploying individual feathers, birds are able to manipulate their bodies to respond to changing flight
requirements. In short, birds have always achieved morphing behavior. As such, engineers of morphing designs have
typically drawn parallels with bird physiology to suggest methods of morphing aircraft. The flight envelope of most birds tends to cover a broad range - from slow, near-hover flight to aggressive dives and pursuits. Birds are able to achieve such a dynamic range through large shape changes to their wings and tail. While the flapping motion is clearly irrelevant to modern aircraft design, many of the shape changes are performed during gliding flight. In particular, birds are able to articulate their wings in a 'craning' motion to vary the dihedral angle, wing area, wing planform, wingspan, vertical center of gravity, and other parameters. These changes allow the animals to quickly transition between soaring, cruising, and descending flight." [1]

Design choices for a warped-wing vehicle will be highly dependent on the structural design of the vehicle, just as it is in nature. This is agreed upon by current research in aeronautics as well as [1]. Some of the benefits of the particular design outlined by [1] include disturbance rejection; that is, that the morphed wing structure can naturally distribute load factors experienced in flight to reduce the effect of turbulence. This is later attributed to "passive aeroelastic response." [1]

The morphed-wing design implemented by [1] and illustrated in Figure 1 includes the wing, horizontal stabilizer, vertical stabilizer, propeller, and fuselage. They also include throttle, rudder, and elevator control to complement the morphed-wing equivalent of aileron control. The [1] morphed-wing surface has a wingtip-to-wingtip freedom of rotation of +/- 20 degrees, and hinges with rotation of up to +30/-20 degrees to allow for wing craning, as shown in Figures 6 through 8 in [1]. Please see Section IV of [1] for details about the aircraft's design, as it is highly similar to what I was envisioning for the project.

In this model, radio controlled actuators are used to morph control surfaces as needed. In my version, on-board gyro or electronic stability information would be used to determine and/or correct the configuration of the vehicle autonomously. Interestingly enough, [1] uses vision to determine the location and relative orientation of the horizon via an on-board wireless camera. This allows for monitoring of the aircraft's position as well as motion. Internal sensors describe the loads and airflow experienced by the aircraft during a number of controlled maneuvering flight experiments described in Section VI of [1]. Interesting suggested results include stability in roll of the "high-hinged" positive gull wing formation at steep (+/- 50 degree) bank angles.

Building the Bird

One of the first challenges is to determine what the kit will be for something like this, as I have little experience in building or modeling. I do know that stability would likely be accomplished with a free gyro. The wing would be a motor-driven warped wing to keep with the "bio-inspired" motif.

For particular details, however, I have contacted Dr. Oh for some advice and direction. He has referred me to http://www.mem.drexel.edu/aerialRobotics for the kit they used for autonomous blimps and other aerial robotics information, including a low-cost contest that they put on here at Drexel.

I have contacted Mr. Mujahid Abdulrahim (author of [1]), and described this project to him, as he has collected a great deal of data in this area already. He suggested taking a look at this website for a simple flight model: http://www.hobby-lobby.com/shockflyer-yak.htm.

The Physical Model: Assembly Model, and Contact Graphs

My physical model is going to be based on the kit models described above, and light for the purpose of having good flight analysis models, which I think would be a nice contribution of this project. According to Mr. Abdulrahim, his data has shown that the simplified model described in the Kit section shows similar flight characteristics under changing conditions to some of the more complex ones that he has encountered.

The CAD Model

The CAD Model is pending the Physical Model, or may omit the Physical Model entirely, due to time constraints, in favor of doing in flight simulation.

Flight Analysis of the Model(s)

Analysis should include: fluid dynamics, airflow over the airfoil, and a wind tunnel simulation. Mr. Abdulrahim has suggested Athena Vortex Lattice (AVL) (described in the survey) for performing some aerodynamic analysis on a geometric shape under changing conditions.

We're interested in looking at flight models of "robot airplanes" that are capable of navigating confined spaces, such as indoor hallways. Particular areas of interest are turning radius, size / payload constraints, and minimum controllable airspeed. For example, it would be ideal to discuss the flight characteristics of a small flying object that would operate indoors and throughout hallways.

Survey of Airflow Analysis Tools

I am starting to look around at the various tools that are available for doing airfoil generation and CFD / aerodynamics analysis. As I find information, I will include it here.

Adams/Aircraft

This seems to be the most promising commercial tool available for airflow analysis.

XFOIL

XFOIL seems to be more suited towards the design of the airfoil. It is documented at http://web.mit.edu/drela/Public/web/xfoil/xfoil_doc.txt. It writes the airfoil geometry to a file, which I am assuming is compatible with the AVL package. If this is true, then XFOIL/AVL represent a very good and free suite for this project.

AVL

Athena Vortex Lattice (http://web.mit.edu/drela/Public/web/avl/) is an MIT windtunnel simulation package for an arbitrary geometry. Like XFOIL, AVL allows for a text-based definition of the airfoil geometry.

According to their documentation, AVL is best suited for "aerodynamic configurations which consist mainly of thin lifting surfaces at small angles of attack and sideslip. Surface geometries and trailing wakes are represented as single-layer vortex sheets, discretized into horseshoe vortex filaments." In short, it's a good candidate for this project.

For computational simplicity, AVL assumes a slender-body fuselage. In fact, they even suggest omitting the fuselage from the analysis if it will have little impact on aerodynamic loading. I hope to include the fuselage for completeness, nonetheless.

Compressibility (which should be negligible at our slow speeds) is modeled using the Prandtl-Glauert (PG) transformation. The PG factor formula shows that at low mach numbers N (as would be the case in our simple model), compressibility is no factor.

To use AVL, one creates two files (and AVL creates a third), as follows:

MeshPilot

CRCCsim: A Model-Airplane Flight Simulation Program

CRCCsim (http://crrcsim.sourceforge.net/) allows us to create a text-based 3D CAD model of the airplane and then simulate it under a "realistic" flight model.

My Experience

Here I will document my experience working with the various relavant tools to model the aircraft.

Adams/Aircraft

I am working through the Adams tutorial to model the aircraft, and then to model its flight characteristics. The list of tutorials is available at C:\MSC.Software\MSC.ADAMS\2005r2\help\mergedProjects\template_based\aircraft\tutorials\tutorials.htm. I will begin by learning the simulation environment using pre-made tutorial assemblies. Once I am familiar with Adams simulation, I will go back and build the models by going through the appropriate tutorials. Finally, it is my plan to build my own model based on my goals.

Full Aircraft Taxi Simulation Analysis

The tutorial I am using first is available at C:\MSC.Software\MSC.ADAMS\2005r2\help\mergedProjects\template_based\aircraft\full_air.pdf on systems with Adams Aircraft installed.

In this tutorial, the aircraft assembly is given and taxi analysis is performed on the model, as described by the tutorial:

"Taxi operations in ADAMS/Aircraft include turning and braking, and the taxi analysis you
perform in this tutorial is a simple simulation of an aircraft travelling straight ahead while
traversing a bump with the brake force ramped up over one second. The brake command
will be defined in the pilot input file. The other parameters in the pilot input file, steering
command, thrust commands, and ground wind speed, are set to zero." Surface and wind conditions can be modeled in this simulation as well, and the results are animated with data plots. I'm assuming this will ultimately lead to an in-air simulation.

Using my newfound knowledge, I tried to run a landing simulation on the same aircraft but I don't think we have the landing license. I then tried to run a maneuvering flight simulation, but am yet unable because I do not know what the "plant input" file format is, that I assume describes the maneuvers to be performed.

Landing Gear Assembly Simulation

Now, I will go back and run through the tutorials to build each part of the assembly (airframe, gear systems, brake subsystems). I shall begin with the landing gear. Although we are not interested in modeling landing gear for this project, it is suggested by MSC that this is a good place to start learning about modeling in Adams/Aircraft. This tutorial was found at C:\MSC.Software\MSC.ADAMS\2005r2\help\mergedProjects\template_based\aircraft\lg.pdf. Here, I create the landing gear assembly using a 1-hub template, and perform load analysis on the assembly. This simulation turned out to be not too exciting as it only showed static forces being exerted on the landing gear. That's important of course, but not for my purposes.

Landing Gear Drop Simulation

Moving on, I try the Drop Gear Dynamics tutorial, found at C:\MSC.Software\MSC.ADAMS\2005r2\help\mergedProjects\template_based\aircraft\lg.pdf. Here I think it starts to get cool. The landing gear wheels are a simple design, but still from a template. My interest at the moment is still in analyzing the models rather than creating them, but ultimately I'll need to create these assemblies from scratch. I'm giving myself some leeway here for now and sticking with the Adams templates until I get the hang of things. This simulation is more interesting -- it actually shows the assembly being modeled as the gear drops. I'm trying to figure out how to save the animation to post here.

Using the Simulator to Make Videos of the Animations

Thanks to Mike's advice and using the postprocessor (F8 in the animation window), I use the view menu to load the animation, then the view menu to set up the camera (position/orientation and pre-set). Finally I can record the animation by setting camera options and playing the animation. The file is saved to the default user directory. My landing gear tutorial movie is available here Media:my_assembly_drop.avi.

Also using the postprocessor (F8) it is possible to load plots instead of animations to view data results. This is not as interesting to describe here.

Since that was fun, I decided to also do the retractable landing gear tutorial for practice. Like the other tutorials, this one starts with a pre-made assembly that we will modify and simulate. The simulation of the gear retract assembly is interesting in that (thorugh the Simulation menu) it allows us to add parameters for wind speed, extra weight, and so on. This proved very easy; having done the previous tutorials, I was able to run the simulation in under 10 minutes, so I'd say I'm getting familiar with the interface. The gear-retract simulation is available here Media:my_assembly_retract.avi. Next will be building the assemblies, unless I find a cool tutorial to do in the meantime.

Full Aircraft In-Flight Analysis

As a last simulation, I tried to run a full aircraft (pre-set civilian jet) maneuvering simulation in given wind conditions while executing a pre-set pilot input (pitch maneuver). Adams ran out of memory, though, which I increased by going to Adams Settings in the Adams program group, going to ASolver, and setting the MD memory model to "huge." That didn't work so I searched the whole Adams settings repository for memory settings, and changed them all to "huge." That worked - talk about brute force, but I forgot this time to specify the pilot input file to the simulation, so my airplane did nothing. Actually it does nothing even when I do specify a simulation -- but I can see discoloration around the wingtips that seems to indicate airflow about the wings. I was hoping for actual maneuvering but to do that I'll have to figure out how to edit the pilot inputs file. It does, however, show airflow analysis (which can be plotted) over the wings during a wind gust. The simulation animation is available here Media:in_flight.avi.

2. Correlate the pitch attitude and glide-slope angle with the angle of attack (α)

3. Determine the short-term pitching frequency response of the aircraft

4. Estimate the aircraft’s pitch damping value

But beware! You need to start the Adams Aircraft template editor for this tutorial. To do this you need to start Adams in expert mode. To do this, go to your home directory (or default adams data directory), open the .acar.cfg file, and set the following line:

ENVIRONMENT MDI_ACAR_USERMODE expert

Tutorials for Building Templates

Now let's build some assemblies. This seems to be accomplished using the C:\MSC.Software\MSC.ADAMS\2005r2\help\mergedProjects\template_based\aircraft\tb.pdf tutorial. I think the assemblies are actually built in the template editor, and then simulated by creating subsystems and assemblies based on the templates.

First, you build the template (in the template editor), then (in the standard interface), you create a subsystem that instantiates the template. Then you create an assembly based on the subsystem(s), and finally you are able to simulate as we have before with the pre-made tutorial assemblies and subsystems.

The template editor is the place to set connectivity parameters among parts. The template editor or the standard interface (subsystem/assembly editor) can be used to set flight characteristic parameters. Naturally, the standard interface overrides the template editor here.

What I'm still not seeing is a place to create pilot input files. However, example pilot input files can be found at C:\MSC.Software\MSC.ADAMS\2005r2\aircraft\shared_aircraft_database.cdb\pilot_inputs.tbl.

My strategy will be to build a simple airframe that I will modify later to see simulation changes. The simulation will hopefully (though I don't know how to do this yet) a constrained environment in which the airplane must maneuver within certain performance parameters.

So the first step is creating the template, which in my case is of type "body." Adams/Airplane allows for the creation of suspension systems, tire/gear systems, etc., that are outside the scope of the bio-inspired project.

I am greeted by a blank canvas with 3 axis and a gravity indicator. I build a new hardpoint at the origin. The tutorial also asks me to create a hardpoint at the origin with a different name (a geometry reference of some type). I'm not sure what this is about but I'm sure it will become clear.

The next step is to build the construction frame. This makes sense. It would appear that the Build menu in Adams Aircraft Template Builder flows in a sequential order. Again I create two "construction frames," one corresponding to each of the hardpoints I just created as coordinate references. Again, I'm not sure about this.

Moving back into the familiar, we build a new general part for the airframe. Luckily there is only one of these. The coordinate reference in this case is the construction frame that corresponds to the origin. So we're not using the "geometry reference" 'extra' hardpoint and construction frame just yet. I was excited to see parameters for mass and inertia settings for the airframe in this dialog box. Unfortunately, we can't play with those just yet. The tutorial recommends keeping the template massless, and setting these parameters at simulation time so that the simulations can be quickly modified. That makes sense, and so that's what I'll do. I click OK and nothing seems to happen.

Next, according to the tutorial: "You must first create a reference marker belonging to the newly-created airframe
part, to allow the geometry to move with the part. You typically create markers by selecting Marker under the Build menu or by using the Command Navigator. Here, however, you’ll use an alternate method of creating markers in ADAMS/Aircraft,
through a marker communicator." So I'll build an output communicator to assign a reference marker to the airframe. This reference marker uses the "geometry reference" hardpoint and construction frame, and its name is comarker_1 (as found by the info button at the bottom of Adams).

Now, using the command navigator (the compass at the bottom of Adams), we create a shape geometry called a shell. This shell uses the comarker reference we created earlier (corresponding to the general part we made previously), and can be based on a body template of its own. I want to make one from scratch (the shell), but for now I will use the FR4Aero template to get me started. I browse for this in the File Name box, and click OK. This results in some interesting but yet unintelligible results. Resizing my view to fit, I quickly see that it is a wireframe of the body. Typing a capital S, I shade the body (and can toggle back and forth). Clearly a future-work item is to later go back and figure out how to create the shells -- as this will be likely the main simulation variable in my project. I am a little disappointed that every path I take in Adams leads me to use *something* as a template. There is very little sense of accomplishing anything completely from scratch. Then again, I suppose none of this is done from scratch anymore as a result of the shear size of the projects that Adams supports. Note that the shell (and other components) refer to a ges_airframe component in the tutorial, but the closest match is ger_airframe. I used ger_airframe for the part references and I think this is right.

Now I understand the airframe geometry reference we created in the beginning. Because the airframe is tied to the comarker, which is tied to that, we can simply move that hardpoint to move the airframe in space. We clearly don't want to have to move the origin. At the moment, the geometry reference is defined as being 0 distance away from the origin, but that's just a relative positioning. Similarly, I can use a new graphic for the aircraft shell body by right clicking the model and clicking Modify.

This tutorial sadly assumes that there will be no engine power or aerodynamics. How lame is that? Therefore, there is no need for input communicators that allow the simulation test rig (or perhaps other parts of the assembly?) to communicate air density and other parameterized information to the template. We'll have to come back to this later as well. I do create some output communicators, but Adams crashes on the last of these. They're related to mounting landing gear assemblies, which is not important for this, anyway. Frustrating to say the least, though. We have a template, anyway.

Tutorials for Building a Subsystem from the Template

Now we create a subsystem assembly from the template we just made. We call the subsystem quick_airframe and base it on the template we just made.

Now we use that subsystem (without any modifications) as the basis for a full aircraft assembly, which we create. We'll use FR4 Aero templates for the other subsystems (suspension, etc.) for now. After all, I have in previous tutorials made the landing gear subsystem assembly, so I should be able to do it again given the time.

And so it happens that my landing gear is attached very nicely to the airframe I created, probably using the communicators we put in earlier. However, I didn't specify where the gear should go -- it just worked. So this makes me think that this is specified either in the wheel subsystems or (maybe more likely?) in the shell template I used earlier. I'm thinking that the communicators I created in the template correspond to the communicators that exist in the gear assemblies, but even then, I never specified a position. It must be in the shell that I used in the last tutorial. I wish I knew how to create *that*. At any rate, my new (and painted) airplane is shown here.

Next we do a landing simulation on this assembly, with the following tutorial-specified parameters:

Aircraft additional mass of about 3000 pound_mass

CG location of about x=107.0, y=0, z=3.0 inches.

lxx = 6e6 pound_mass*inches**2

lyy = 5e6

lzz = 6e6

lzc = 2e6

On the MEM machines, you can't change video resolution and thus can't see the "Submit" button on the simulation windows. But I have figured out through painful trial and re-entry that it is 4 tabs from the "Create Analysis Log File" check box, so if you highlight that and hit tab 4 times, then space, you'll be hitting the submit button. You also can't open the Adams file system to browse the shared database, so you have to go to notepad and do File->Open. In addition, Internet Explorer doesn't let you navigate to the C drive to get around this, but you can instead type "Desktop" into the IE address bar, and then navigate to "My Computer," and finally the C drive.

At any rate, the simulation crashed. This could be because the one output communicator from the template also caused Adams to crash.

Creating a Shell and Pilot Input File from Scratch for Simulation

The tutorials provided by Adams lack the bottom-up creation of shells and pilot input files for real simulation. Sadly Google lacks this information as well, so I'm going to just try and figure it out. This will be a fun time to be had by all, and the experience will be described here.

Athena Vortex Lattice (AVL)

Awaiting a response from UMD on aerodynamic analysis of flapping wings, I am moving on to the AVL package from MIT labs. By AVL's own admission, AVL is not intended for extreme flight maneuvers; the assumptions and limitations on the analysis essentially expect "normal" flight maneuvers, which is fine for this simulation effort. Creating a simulation consists of producing three input text files, which are described here. The descriptions are first digested from the documentation, which I will then apply and describe. Running AVL then consists of feeding it these three files.

Geometry Input File (.avl)

The geometry system is an intuitive 3-space (x: downstream, y: right wing, z: up). The file begins with the title

This input file begins with the title, freestream mach number (0 is fine for low speed operations), a triple representing symmetry information within the geometry, a triple representing the area, chord and spam that will be used as the reference fomr pitch, roll and yaw movements, and finally a triple giving the default center of gravity location in 3-space. Each piece of information is stored on a separate line.

Optionally, the next line can contain the profile drag coefficient, which is applied at the XYZref point defined earlier. Some data, such as the mach number, XYZref and drag coefficient can also be set (and overridden) in the Run file, described later.

The reason for specifying optional symmetry in this file is because, if it is specified, only half of the geometry file must be specified. The documentation points out that this is not often done in reality; however, this would make sense for our simulation.

Finally, the actual surfaces can be defined.

Each surface consists of at least two sections. Surfaces consist inexplicably of horseshoe-shaped vortices specified about the surface. After the surface is named, the attributes are specified as a 4-tuple, consisting of the number of chordwise horseshoe vortices and the spacing (spacing values are usually 1 to specify a cosine spacing), and optionally the same for the spanwise horseshoe vortices.

Surfaces can be indexed by an LSURF value, that indicates that the surface belongs to a larger group of surfaces with the same LSURF index value.

To use symmetry (specified by iYSim in the header), the YDUPLICATE keyword is used to create another surface that mirrors the current one.

The SCALE and TRANSLATE keywords are obvious, and take triples X,Y,Z. Same with ANGLE but it takes a single value.

Next, the SECTION keyword specifies the airfoil, and takes a triple for the leading edge, the chord's X displacement, the angle of incidence, and optionally the number of spanwise vortices and spacing (if not specified in the initial SURFACE definition).

The AIRFOIL keyword declares an airfoil with shoelacing X,Y point defintions.

The CONTROL keyword creates a control surface, such as an aileron or flap. It takes a name, the deflection gain, the X displacement of the hinge, an X,Y,Z triple specifying the hinge movement, and a scalar that constrains movement of the hinge to the positive or negative direction.

For example, if CONTROLS are defined as follows:

CONTROL
aileron 1.0 0.7 0. 1. 0. -1.0

CONTROL
flap 0.3 0.7 0. 1. 0. 1.0

The overall deflection (from the documentation) will be

control_surface_deflection = 1.0 * aileron + 0.3 * flap

The documentation goes on to describe mixing control surfaces (i.e. a flaperon).

Another interesting possibility disucssed by the documentation is to have non-differential controls. This is done by manipulating the hinge direction scalar to something other than 1 or -1. For example, setting one aileron to have a scalar multiplier of 1.0 and the other of -2.0 will allow one aileron to deflect twice as much as the other and in the opposite direction.

Once the surfaces are defined, the body can be defined.

The BODY keyword specifies a name, number of source-line nodes and spacing parameter. Many SURFACE keywords then apply to the BODY section (such as YDUPLICATE, SCALE, TRANSLATE, etc.).

Mass and Inerta Input File (.mass)

Next comes the mass and inertia file. It's optional but defines the actual masses and inertial forces applied by the geometry. LUnit, MUnit and TUnit scale the translation (XYZ), mass and time tables as needed in the actual simulation (for example, if the data given in the AVL geometry is in inches instead of meters, it could be scaled with this constant). Standard gravity and air density, for example, are also set as constants. Then, simply specify on each line the following information:

mass x y z Ixx Iyy Izz [ Ixy Ixz Iyz ]

Where the x,y,z coordinates refer to the center of gravity (CG) of the item being described. A mass line beginning with a + is a scalar offset, and a mass line beginning with a * is a scalar multiplier. These scalars are applied to all data below it, until another scalar line is encountered.

Behavior Simulation Input File (.run)

Finally, we can specify the .run file. The documentation claims that this file is generated by AVL, and not by the human, but I am not sure how. Moreover, I'm not sure how to simulate maneuvering flight. They do claim that the .run file can be manipulated by a human, though. It would appear that this file is created by loading the .avl and .mass files, and then using the OPER command directly within the AVL interface. The documentation claims it is possible to, for example, simulate an airplane in a looping maneuver, and this is a good representative example of maneuvering flight that I'd like to simulate. I shall run through this and document how that goes. The sample run files are found in the AVL tar file, under the avl/runs directory.

Example files

Creating and Viewing An Airplane

I loaded the runs/vanilla.avl geometry description into AVL, and opened it in Notepad. It makes a lot more sense now. One thing I wasn't sure about was that the airfoil referred to an AFILE, which turned out to be the geometry file describing the shoelace X,Y coordinates of the airfoil. I opened the geometry plot by typing OPER (note that commands depicted with a period in AVL, such as .OPER, represent a submenu of commands), then G, and I was able to view the plane. Although specifying the geometry from scratch looks tedious, it makes very logical sense and is reproducable. Here's the vanilla sample:

Running Simulations

Simulations take on two forms, it seems: geometric/aerodynamicsimulations and eigenvalue simulations. For this class we're probably more interested in the aerodynamic simulations as the eigenvalue dumps will be of little value in the time available.

Working again with the vanilla plane, I load that into AVL. I enter OPER mode and view the graph of the aircraft geometry by typing G, as I have before. Now I enter TR to view trailing vortices resulting from airflow on the airfoil; this doesn't produce any values just yet, but it does result in the following graph.

I then set the airplane run case to consist of a coordinated (no yaw moment) 30 degree turn, and plot that graph. This is described in the session1.txt documentation and I will digest it here. The plot looks as follows, and it is notable to see the up elevator required to remain level in the turn.

Creating NACA Airfoils for Performance Simulation

Three scenarios are generated for performance analysis and comparison of the different NACA airfoils to be created in AVL. These scenarios include an enclosed indoor environment, such as a series of hallways, a constrained outdoor environment like an arena or stadium, and fine navigation of ductwork. Each of these scenarios presents a real problem to be addressed by UAV.

Here, we shall simulate NACA airfoil designs, which are specified by the following formula:

Given that x and y is the position along the x-axis and corresponding y-axis thickness. t is a parameter that specifies the maximum thickness of the airfoil. The airfoil's depth is specified by a cylinder of radius r = 1.1019 * t^2.

This is added to the mean camber line and then the sine/cosine paramters are used to deermine the x and y coordinates. The Maple printout shown here Media:maple_naca_airfoil.pdf should take care of it, but Maple can't compute the plot for some reason. Luckily, someone has handled this and I am going to try their tool to compute the points that I want. This is available at http://www.pagendarm.de/trapp/programming/java/profiles/NACA5.html as a Java applet. It computes the points based on the NACA5 standard, which provides the required parameters for the equations described in this section and in associated resources. A similar tool, called foilgen, was available at http://www.aoe.vt.edu/~mason/Mason_f/MRsoft.html. A Matlab program called Tornado is also available at the same site for airfoil analysis.

The basic idea is that these formulas can be run with the given NACA parameters. From the PDF above, A NACA airfoil is a 4 to 6 digit numerical representation of the form:

NACA XXMP (for example, NACA 2412)
where XX is the maximum thickness ratio x/c (c = the mean camber length)
M is the maximum value of the mean line in hundreths of chord
P is the chordwise position of the maximum camber in tenths of the chord

More precisely, NACA 2412 corresponds to a 12% thick airfoil, a max value of the camber line of .02, at x/c = .4.

The 5 digit NACA representation adds an L value at the beginning, representing the amount of camber, such that the lift coefficient is 3/2 L in tenths.

These formulas and the NACA2412 wing generate the following point-wise descriptions of the wings, from FoilGen Media:naca2412.pdf (X,Y values only) and Media:naca2412_full.pdf (with all paramter information). The base X,Y file can be made into an AVL geometry file.

In fact, the X,Y file created by foilgen.exe can be used exactly as an avl AFILE reference, which defines the shoelace structure of the airfoil. Just take out the header garbage, the line giving the number of data points, and any titles (except the main title) related to the Upper and Lower Surface.

I generated the .dat file, and modified the vanilla2.avl file that came with AVL to work with it. For now I gathered the given plane.mass file also from the AVL distribution. I'll integrate that later, if appropriate.

Reading more closely, I see that XFOIL (also from the AVL folks) is a tool that will also output these coordinates. My confusion is that I was creating the coordinate file and using it as the AFILE in the AVL spec, but it wasn't really drawing it to my spec. Moreover, AVL examples use the same coordinate file for multiple surfaces. Could this just be a case of symmetry? How would flaps have the same configuration? Or would the flaps actually be part of the wing and therefore have the same x,y initial coordinates, that are then constrained to move in the AVL file? There's a lot going on that is not immediately obvious to me.

Using a NACA airfoil generated by XFOIL and the vanilla airplane, I build a very simple (triangular) fuselage. I'll modify it to have a more aerodynamic shape as time permits, but for now I'm just getting used to the coordinate system. It appears that I am not a spacial thinker, as it took me several iterations to try and get a cylinder, before giving up and making a triangle.

Now, upon trying to connect the triangular shape to the tail (and to connect it to the front at a point for the nose), I get an error from AVL: "Insufficient number of spanwise vortices." Googling around, I find a tech report about someone using AVL. This is great because there is really very little out there to help! It can be found at http://www.viscerallogic.com/paul/works/AVL%20Report.pdf. According to Paul Dorman in this article:

"In the SURFACE section of the geometry file, the third number after the name gives the number of spanwise vortices (Nspanwise) to distribute across the wing. If there are too many sections given, AVL gives up and crashes with this error message. I experimentally determined that Nspanwise must be about 1.26 times the number of sections."

Thus, I have fixed the problem by removing the SURFACE NSpanwise specification, and setting the individual SECTION NSpanwise values to 1.5 times the number of sections. While I was at it, I found Dorman's UAV, which is a more non-trivial model that I can play around with.

My first attempt produced a very simple airframe with a nice sized wing and light payload. Likely a good general purpose design (if it were sealed!) for the moment, but we shall try to execute basic turns, etc., to see how it holds up. I first compute the forces on the airframe by typing X (to run the calculations), then FT. The forces are as expected from the mass file; the airframe itself adds little weight. I then type HM, and notice no hinge (aileron, elevator, rudder) deflection to maintain level flight, except for very slight (2e-6) rudder deflection, which is likely explained by wingtip vortices acting on the tail of the airframe. A screenshot showing this data is shown here:

Simulating a Scenario

Now we will create a video of an airframe in a simple scenario. I will start with the bd airframe, a Bubble Dancer RC model. The steps to create a video simulation are described in session2.txt. Once the aiframe is created, the masses applied and a run scenario created (provided in the .run file, although it could also be created within the AVL interface), it is simulated. We will simulate a 60 degree banked turn and determine the turn radius and speed needed to sustain that turn in a hallway.

The run case is executed as usual, but the simulation can be viewed by entering Eigenvalue mode (.MODE at the main menu). Typing "N B" we expand on the roots of the eigenvalue computation; at which point we can type X to examime a node, and select a root to enter playback mode. IXIX and IZIZ are used to set default inerta values on pitch and yaw before running the eigenvalue computation.

In this case, we see that the 60 degree bank can be maintained without loss of altitude. It is found that the bank be maintained at 8 meters per second (rather fast) with a bank radius of 4m. This is slightly outside the width of a hallway turn. Perhaps airspeed can be compromised. A slight descent is present in this simulation that will not be adequate for the hallway turn. The file is available here: Media:bd60_video.avi.

The airframe data shows reasonable pitch up (13 degrees) and rudder control inputs are necessary to coordinate the turn. This airframe will likely satisfy the hallway turning requirement, as long as enough airspeed can be removed from the simulation without compromising a steady altitude. The data dump is availabhe here:

Using the OPER menu, then C1, the scenario can be edited and previewed without the video. That is, one can apply velocity and bank angle to determine the turning radius required. If the airspeed is too slow and a stall would result, the simulation fails with a bad alpha value. I tried a couple of scenarios that didn't quite cut it: I was aiming for a 4 meter turn radius with no more than .7meters/second loss in altitude, regardless of airspeed; though this isn't exactly realistic since we need to strap an engine on this thing that can sustain the speed. After a few trial and error sessions, I came up with a scenario that fit: an 80 degree bank (wow!) at 15 meters/second (about 33 mph). So realistically this glider doesn't won't do without some power behind it, but I've included the video to show it will work. I know empirically that I can't do much better, because there is little to no pitch up (theta) required to sustain the altitude in the turn. Any less speed and I'd be descending too much, any more and my turn radius would be lost.

On the other hand, my aircraft which was very, very light weight, took a few iterations before I got it right as well. For this aircraft, it was easier to get a small turning radius (3 feet), using a bank angle oscillating between 1 and 10 degrees (very light banking) at 2 feet per second of forward velocity. Slight pitch up through the turn is used to maintain altitude, which is kept constant through the turn. As bank angle decreases, so does pitch up, until the aircraft is actually slightly pitched down to avoid climbing from the excess airspeed. The video is shown here. Some reasons for improvement involve the very large wing, large aileron, and large rudder control surfaces. The elevator is also proportionally larger but this is of little consequence in this scenario. However, it should also be noted that these masses are considered rather lightweight, and this may or may not be realistic. But we will make that assumption for now, and see that the addition of that mass should be easily compensated for by extra bank or airspeed. There was plenty "left over" from this run, and that's a start.

Drexel Autonomous Systems Lab

This is Dr. Oh's lab from Mechanical Engineering. Check out their Blackhawk: http://dasl.mem.drexel.edu/Blackhawk.htm. They use a Microstrain's 30 gram 3DM-GX1 inertial measurement unit (IMU) to determine aircraft attitude in flight.