cromagnam - purdue engineering · web viewthe stable c.g. location is currently performed manually...

Contents

I IntroductionII Comparison to Conceptual Design

1 Aerodynamics – Missy Hartwell………………………………………………………4 1.1 Introduction 1.2 Theory and Equations 1.3 Running the Code and Results 1.4 Conclusions

2 Aeroheating – Brad Crosson…………………………………………………………..25 2.1 Introduction 2.2 Methods and Calculations 2.3 Results 2.4 UHTC Analysis 2.5 Trade Studies 2.6 Discussion/ Reflections

3 Thermal Protection System – Robert MacDermott…………………………………..41 3.1 Introduction 3.2 SODDIT 3.3 Validation of SODDIT 3.4 Matlab SODDIT Interaction 3.5 TPS Iteration Cycle 3.6 Material Selection 3.7 Optimization Program 3.8 Iterations 3.9 Results

4 Structures – Lloyd Droppers………………………………………………………….72 4.1 Introduction 4.2 Requirements 4.3 Vehicle concept 4.4 Loading & Boundary Condition 4.5 Analysis Method 4.6 Matlab Trade Study 4.7 Iterations 4.8 Final Vehicle 4.9 Conclusion

5 Propulsion – Thomas Jennings……………………………………………………….93

6 Mars Trajectory – Mike Grant………………………………………………………..94 6.1 Introduction 6.2 Background

1

6.3 Fortran Simulation Overview 6.4 The Trade Space 6.5 The Genetic Algorithm – An Overview 6.6 Genetic Operations 6.7 Advantages of the Genetic Algorithm 6.8 Application of the Genetic Algorithm to Martian Atmospheric Flight 6.9 Fitness Evaluation 6.10 Fortran Trajectory Simulation Efficiency 6.11 Critical Influences on Trajectory Performance 6.11.1 Shadowing 6.11.2 Nose Radius 6.11.3 Viscous Drag Interaction and Final Iteration Results 6.11.4 Minimizing the Effects of Viscous Drag Interaction 6.12 Direction for Further Analysis 6.13 Execution of the GA and Analysis Scripts 6.14

7 Venus Trajectory – Greg Henning…………………………………………………..122 7.1 Initial and Final Conditions 7.2 Venus Properties 7.3 Trajectory Design 7.4 Vehicle Control 7.5 ΔV Analysis and Comparison 7.6 Iteration Process 7.7 Results and Discussion 7.8 Conclusions and Recommendations

8 Mars Multidisciplinary Design Optimization – Tony Sanders………………………150 8.1 Introduction 8.2 Method 8.3 Overview 8.4 Explanation of Code

9 Venus Multidisciplinary Design Optimization – Rob Fink…………………………1689.1 Overview9.2 BFP Analysis9.3 Spear Analysis9.4 Conclusions

10 Earth Multidisciplinary Design Optimization – Tim Kite……………………….…17810.1 Introduction10.2 Assumptions10.3 Design Parameters10.4 Team Interaction and Interdependency10.5 Design Methodology

10.5.1 Trajectory Theory and Development

2

10.5.2 Control Law Theory and Development10.5.3 Optimization Method

10.6 Iterations and Results10.7 Conclusion10.8 References

11 Systems Engineering – Michael Moessner………………………………………..194 11.1 Introduction 11.2 Components 11.3 Iterations 11.4 Conclusion

III Conclusion

Appendix A: Aeroheating……………………………………………………………...216

Appendix B: Plots for all Earth Re-Entry Iterations…………………………………..223

Appendix C: Trajectory Appendix……………………………………………………..242

Appendix D: Three Venus Control Methods…………………………………………..252

Appendix E: Detailed description of SODDIT and SODDIT/Matlab programs………260

3

1 Aerodynamics – Missy Hartwell

1.1 Introduction

The Fall 2005 mission required a vehicle that must perform an aero gravity assist for a

Mars- Venus sample mission returning to Earth. Gravity assist maneuvers along with

aerodynamic forces have been used in the past to perform interplanetary missions to enable

reductions in cost. The Fall 2005 mission was unmanned, similar to Galileo, and required to

carry only scientific instruments that sampled atmospheric data along the way. In order to

perform this sort of mission, a hypersonic vehicle with a high L/D was desirable. The analyses

computed in the past generally assumed a fixed L/D ratio or fixed drag polar independent of

Reynolds number and Mach number, and did not analyze the thermal protection system or affect

of mass and volume. Because the trajectories are heavily dependent on these parameters, more

analysis was performed on varying L/D and viscous interactions effects in this report.

The objectives and goals for the aerodynamicist in the mission were to: evaluate vehicle

shapes, obtain methods to evaluate hypersonic Cl, Cd, L/D (including Newtonian, viscous, and

skin friction), pitching moment, static stability, and trim, and provide a subroutine for the

trajectories aerodynamics.

Step one for the aerodynamicist was selecting a vehicle. In order to select a vehicle for

the mission, research on hypersonic lifting bodies was first performed. After many publications

were read and hours of research conducted (Aerospaceweb.org, Advanced Topics in

Aerodynamics website, NASA’s SHARP vehicle), it was noted that the waverider, a sharp

leading edge wedge-like vehicle, was most often cited. For this reason a wedge was considered

for a preliminary vehicle design as well as a cone, circular cylinder, sphere, and flat plate. In the

4

end, a wedge was chosen for its high internal volume and flat plate behavior when flown at an

angle of attack higher than the included angle of the wedge. (The flat plate behavior is desirable

because it has the highest L/D.) The wedge has a rounded nose tip (modeled as a hemi-

cylindrical) and a flap attached to the back for trim control and stability.

1.2 Theory and Equations

In order to evaluate the performance of the wedge, several codes were written in Fortran

and then analyzed using Matlab scripts written by Tony Sanders (MDO Mars). The Newtonian

hypersonic theory was used to derive the equations for the flow around the plate. The Newtonian

theory states that when a uniform stream of particles impacts a body at an angle of attack, the

normal component of each particle’s momentum is transferred to the body while the tangential

component is preserved. This method is very inaccurate at subsonic speeds but is relatively

accurate for hypersonic speeds because the body moves so quickly. The Figure below shows the

Newtonian flow field.

Figure 1.1 Newtonian Impact Theory

5

Using Newton’s sin squared law, equations were derived for the aerodynamics of the

wedge with the help of Tony Sanders, MDO Mars. The equations were derived from Anderson’s

“Hypersonic and High Temperature Gasdynamics” (Ref 1.2) and Clark and Trimmer’s

“Equations and Charts for the Evaluation of the Hypersonic Characteristics of Lifting

Configurations by the Newtonian Theory” (Ref 1.3). The following is a list of variables used in

the derivations:

Lplate= length of wedge

Lflap= length of flap

rnose=nose radius

width= width of plate

δ=wedge included angle

xcg= center of gravity as measured along centerline from the reference point at the nose

zcg=distance along the z-axis from the center line to the center of gravity

Ycg= distance along y-axis from centerline to center of gravity. In the diagram below, it

is out of the page.

α = angle of attack the vehicle is flow at, has no relation to delta or beta in the definition.

Referenced as angle from velocity vector to bottom of wedge.

β =angle of flap, as measured from bottom of wedge to the flap

Sref=reference area of vehicle, used for non-dimensionalization

lref =reference length, entire length of vehicle, wedge +flap

lext= extension between lplate and lflap

The figure below is a sketch of the wedge geometry. All angles are positive downwards

and when the angle of attack is greater than the included angle of the wedge, the top surface is

6

shadowed. Because the least amount of drag was desirable, the wedge was never flow at angle of

attack less than the included angle of the wedge and therefore no aerodynamic data was analyzed

there. At angles of attack higher than the included angle of the wedge, the upper surface was

shadowed and cl=cd=0.

Figure 1.2 Wedge Geometry

The codes from previous years that were given to the aerodynamicist to modify to model

a wedge were:

Aerodat- main program where parameters are identified and moments, lift and drag are

calculated.

7

Aeroprop- generates cmcg vs alpha for a range of different flap angles. This is inviscid

analysis.

Aerotrim- subroutine that provides trimmed aerodynamic parameters for the vehicle. At

flight points, Cm=0 for trim and the slope of cmcg vs alpha must be negative for static

stability.

Altvmap- Used to generate various plots such as viscous drag, Newtonian drag, skin

friction drag vs altitude for various velocities, L/D vs altitude, etc.

Of important note is that roll and yaw were not taken into consideration for the sake of

time and difficulty. Also, the aerodynamics of ablating TPS were not considered. The vehicle

remained in hypersonic flight for the duration of the mission; therefore supersonic analysis was

not performed.

The main code, aerodat, was rewritten using the Newtonian hypersonic theory to model

the flow around a wedge. The code was rewritten a total of four times as a result of low L/D data

(sometimes even negative) that was returned. (Writing codes to model hypersonic flow is easy at

first glance but difficult to get results) After many hours of debugging, staring at a computer and

learning Fortran- specific coding, “good” results (higher L/D) were obtained and the code was

finalized. The following equations were derived using Newtonian hypersonic theory. (see

appendix for codes and specific equations numbers from which they were derived)

Error! Objects cannot be created from editing field codes.

Equation 1.1 Newtonain Hypersonic Theory

Below, xu_x, xu_z, xl_z are distances from the point where the center of pressure acts on

the upper and lower surfaces of the wedge to the cg location in the x and z direction. There were

8

used in deriving the cmcg for the wedge. Because we were dealing with essentially two flat

plates, the center of pressure is assumed to act at the center of the plate.



Equation 1.2 Newtonian Hypersonic Theory Con’t

Below, xf_x, xf_z, are distances from the point where center of pressure acts on the flap to the cg

location. There were used in deriving the cmcg for the flap.




Below are the equations derived for the nose of the wedge.

Error! Objects cannot be created from editing field codes.Equation 1.4 Newtonian Hypersonic

Theory Con’t

Finally, the total cn and ca were calculated and the Cl and Cd Newtonian were found.



In addition to the Newtonian drag, viscous drag and skin friction drag also act on the vehicle.

The role of viscous interaction drag was important in the analysis because as a body travels

through air, a boundary layer (a thin region near the body surface) forms. This is not a concern at

subsonic speeds but as the speed increases, the flow temperature increases due to skin friction

causing the boundary layer to grow very thick. The primary reasons why the boundary layer

9

increases are in increase in viscosity and a decrease in density. The result of this is that the

boundary layer thickness varies as the square of the Mach number.

The results of this phenomena are seen later in the L/D plots when flown at different altitudes.

Viscous interaction was computed by first finding the transition location from laminar to

turbulent flow from the Reynolds number and then using that to calculate the viscosity from

Sutherland’s Law. The governing equation is:


Equation 1.6 Viscous Drag

Hypersonic skin friction was also of vital importance because the growth of the boundary

layer at hypersonic speeds results in a growth of skin friction. The skin friction drag was

calculated also by first finding the transition location from laminar to turbulent flow from the

Reynolds number. Then, the skin friction due to laminar flow was found as well as skin friction

due to turbulent flow.

1.3 Running the Codes and Results

After all the equations were derived and modified in the aerodat code, the aeroprop code

was modified to run at the desired angles of attack and increments chosen by the aerodynamicist.

The aerotrim code was then modified to run at the desired flap angles and cg locations chosen by

the aerodynamicist. The flap angles chosen to run at were critical. By increasing the range of flap

angle, the vehicle was able to trim at a wider range of cg locations.

Once all the codes were modified and ready to run, the vehicle parameters (lplate, lflap, width,

rnose, width, mass, ycg, zcg, alpha, sigma, delta, lext) for the given iteration were put into a

matlab script written by Tony Sanders. (Trajinputmatrix, Aeroinputmatrix, Altvmapinputmatrix)

10

The updated Fortran files were run and then the Matlab scripts were run to help plot the

data and interpret the results.

One of the primary concerns for the Fall 2005 mission was obtaining a high enough L/D

to maintain the flight path given by Tracey that provided the proper trajectory without

accumulating a lot of drag while flying in the atmosphere. Also of great importance was the

trimming capabilities of the vehicle while in flight. The center of gravity location in comparison

to the center of mass played a vital role in determining what angles of attack the vehicle can fly

at. The center of gravity location was an iterative process between the aerodynamicist, systems

person, and trajectories people (Mike M., Greg, Mike) and proved to be one of the limiting and

most difficult parameters to iterate on.

To start, Aeroprop, an in-viscid analysis, was run to see the max Cl/Cd obtainable for

each angle of attack chosen. A plate length, flap length, width, included angle of the wedge, and

nose radius were chosen and the aeroprop code was run. For the first trade study, aeroprop was

run with the following parameters and the plate length was varied from 2 meters to 8 meters.

Table 1.1 Parameters for Final Iteration

lflap rnose delta width zcg

0.25m 0.001m 4 deg 1.25m 0.028m

After analyzing these results it was concluded that changing the length of the plate

doesn’t affect the L/D. It was later found that the vehicle length was more vital from a

trajectories point of view rather than aerodynamics. If the trajectories people needed a longer or

shorter vehicle, it was not a primary concern for the aerodynamicist.

11

Cl/Cd max vs Alpha for Various Plate Lengths

2.5

3

3.5

4

4.5

5

4 9 14 19 24

alpha (deg)

cl/c

d

lplate=2m lplate=4m

lplate=6m lplate=8m

Figure 1.3 Cl/Cd max vs Alpha for Varying Plate Length

As seen above, the max inviscid Cl/Cd obtainable was around 4.4 at an angle of attack of 7

degrees for a nose radius of 0.001m.

Next, a trade study on the effect of nose radius was performed. Aeroprop was run with the above

with lplate=3.575m, width=1.25m, delta=0 deg, lflap=0.25m, and rnose=.00001m to 0.005m. It

was run with an included angle of 0 degree to try to model flat plate behavior.

12

Figure 1.4 1Cl/Cd Max for Various Nose Radii-In- Viscid

As seen seen in the figure above, the nose radius has an extremely large effect on the Cl/Cd. (It

does not affect the lift, rather the drag but Cl/Cd was of interest to the aerodynamicst). For

rn=0.005m, the Cl/Cd max is around 2. As the radius was decreased, the Cl/Cd shot up at very

low angles of attack. For a nose radius of 0.00001m, Cl/Cd max was 23. As the nose tip radii is

decreased, the overall heating is decreased resulting in less drag.. For an infinitesimally small

nose radius, the trend is Cl/Cd approaching infinity. However, according to the methods handout,

the minimum nose radii one should look at is 1mm.Therefore, a limiting factor in achieving

higher L/D is the nose radii. Aeroprop was also run to see the trimmable xcg locations. The use

of the flap attached to the back was primarily for the trim and pitch control. By changing the flap

angle, the vehicle was capable of trimming at different angle of attack. To see where the vehicle

13

was capable of trimming, the aeroprop code was run at angle of attack -35 degrees to 35 degrees

for a selected number of xcg lcoations with the parameters of the current iteration. Plots of cmcg

vs alpha were generated and for the vehicle to trim, Cm=0 and the slope of cm vs alpha must be

negative. The plots below are for the last iteration run.

Table 1.2 Parameters for Last Iteration

lplate lflap width rnose delta lext

3.575m 0.25m 1.25m 0.001m 4 degrees 0.3m

6 8 10 12 14 16 18 20 22 24 26 28-0.04

-0.03

-0.02

-0.01

0

0.01

0.02

Plot of Cm,cg versus

(deg)

Cm

,cg

lplate= 3.575lflap= 0.25width= 1.25rnose= 0.005xcg= 2.0279ycg= 0.028

Flap Angle ( ) = -23Flap Angle ( ) = -21Flap Angle ( ) = -19Flap Angle ( ) = -17Flap Angle ( ) = -15Flap Angle ( ) = -13Flap Angle ( ) = -11Flap Angle ( ) = -9Flap Angle ( ) = -7Flap Angle ( ) = -5Flap Angle ( ) = -3Flap Angle ( ) = -1Flap Angle ( ) = 1Flap Angle ( ) = 3Flap Angle ( ) = 5Flap Angle ( ) = 7Flap Angle ( ) = 9Flap Angle ( ) = 11Flap Angle ( ) = 13Flap Angle ( ) = 15

Figure 1.5 Trimming Capabilities for Xcg=2.02

The above figure is for the xcg location for the final iteration. At this xcg location, as seen from

the figure above, the vehicle is capable of trimming at a flap angle of 1 degree for smaller angles

14

of attack and -1 degree for larger angles of attack. The trimming capabilities at large angles of

attack was important for Earth trajectories while Venus and Mars needed to trim at lower angles

of attack.

Shown below are other trimmable xcg locations. These were needed because the systems person

(Mike Moessner) needed a range of xcg locations rather than one specific location. After a

certain location, it was nearly impossible to move components around and ballast was added or

subtracted to move the position of the center of gravity. This was a part of the iterative process in

that the aerodynamicist gave the systems person a range of cg locations then he moved things

around and sent the data to the trajectories to see if the location gave good results. The

trajectories were then sent to TPS and if necessary, the cycle was once again repeated. The xcg

range given to the systems for trimmable states was 1.84m -2.1m.

15

6 8 10 12 14 16 18 20 22 24 26 28

-0.04

-0.03

-0.02

-0.01

0

0.01


(deg)

Cm

,cg



Figure 1.6 Trimming Characteristics for Xcg=1.97m

16

6 8 10 12 14 16 18 20 22 24 26 28

-0.06

-0.05

-0.04

-0.03

-0.02

-0.01

0

0.01


(deg)

Cm

,cg



Figure 1.7 Trimming Locations for Xcg=1.85m

Altvmap was run in order to compare Lift /Drag and coefficient of drag at different altitudes and

different velocities without flying through a specific trajectory. (The lift and coefficient of lift are

not a function of altitude). The following are plots returned from altvmap with the below

parameters:

Table 1.3 Final Iteration Parameters

17

lplate lflap width rnose delta lext

3.575m 0.25m 1.25m 0.001m 4 degrees 0.3m

0 1 2 3 4 5 6 7 8 9 10

x 104

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000Components of Drag vs Altitude

Altitude (m)

Dra

g (N

)

= 7

Figure 1.8 2 Components of Drag at 6,000 m/s, alpha= 7 degrees

Plotted above are the different components of Drag at different altitudes. As seen in the figure, as

the altitude increases, skin friction, viscous, and Newtonian drag all decrease. The skin friction

drag is very small relative to the other components. This may be due to a bug in the code,

however, the aerodynamicist was not able to find this bug.

Although the drag itself decreases with increasing altitude, the coefficient of drag increases. This

is shown in the figure below. The coefficient of drag steadily increased as the altitude increased

until around 55 kilometers where it leveled off at cd=0.025. This phenomena of increasing cd

became the primary concern for the mission.

18

Skin Friction

Newtonian

Total

Viscous

0 10 20 30 40 50 60 70 80 90 1000

2000

4000

6000

8000

10000

Comparison of CDTOTAL and Total Drag vs Altitude

Altitude (Km)

Dra

g (N

)

0 10 20 30 40 50 60 70 80 90 1000.005

0.01

0.015

0.02

0.025

0.03

CD

Figure 1.9 Components of Cd and D for 6,000 m/s, alpha=7 degrees

In order to see exactly where the increasing cd was coming from, it was broken up into skin

friction, viscous, and Newtonian components. These are plotted below. As seen in the figure, the

Newtonian and skin friction drag remained constant as the altitude changed. However, the

viscous interaction coefficient of drag increased dramatically as the altitude increased. This is a

result of the changing density in the atmosphere. At higher altitudes the air is less dense. Because

Cd is inversely proportional to density, as the density decreased the Cd increased. In order to

achieve a higher Cl/Cd, the vehicle must remain in flight at lower altitudes. As seen in the figure

below, at high altitudes, around 56 km, the viscous drag contributed approximately 70% of the

total drag. However, it isn’t till around 40 kilometers that the viscous interaction drag dominated.

At the least, around 20 km, the viscous interaction drag contributed around 30% of the total drag

and for this reason it is much more beneficial to fly at low altitudes. This is discussed later by the

trajectories people.

19

Cd vs Altitude

0.00E+00

2.00E-03

4.00E-03

6.00E-03

8.00E-03

1.00E-02

1.20E-02

1.40E-02

1.60E-02

1.80E-02

2.00E-02

0.00E+00 2.00E+04 4.00E+04 6.00E+04 8.00E+04 1.00E+05 1.20E+05Altitude (m)

Cd

newtonian skin friction

viscous

Figure 1.10 Cd vs Altitude - Skin Friction, Viscous, Newtonian

Cd vs Altitude

0.00E+00

5.00E-03

1.00E-02

1.50E-02

2.00E-02

2.50E-02

3.00E-02

0.00E+00 2.00E+04 4.00E+04 6.00E+04 8.00E+04 1.00E+05 1.20E+05Altitude (m)

Cd

newtonian

skin friction

viscous

total cd

Figure 1.10 Cd vs Altitude - Skin Friction, Newtonian, Visscous, and Total

20

Because viscous drag was such a larger contributor to the overall drag, it was important to

compare the inviscid and viscous L/D max. Shown below are two plots of viscous L/D at 6,000

and 10,000m/s at alpha=7 degrees. It was flown at 7 degrees because this was where the max

L/D occurred.

0 10 20 30 40 50 60 70 80 90 1001

1.5

2

2.5

3

3.5

4L/D versus Altitude

Altitude (Km)

L/D

= 7

Figure 1.3 L/D vs Altitude for 6,000 m/s , alpha=7 degrees

21

0 10 20 30 40 50 60 70 80 90 1001

1.5

2

2.5

3

3.5

4L/D versus Altitude

Altitude (Km)

L/D

= 7

Figure 1.13L/D vs Altitude for 10,000 m/s , alpha=7 degrees

As seen in the figures above, the L/D changed very slightly as the velocity changed from 6,000

m/s to 10,000 m/s. At 10,000 m/s the L/D max was at 3.74 and it leveled off at 1.22 around an

altitude of 52 kilometers. At 6,000 m/s the L/D max was at 3.88 and it also leveled off at 1.22 at

an altitude of 56 kilometers. This shows that L/D decreases very little as the velocity is

increased. However of important note is that the L/D max is 3.88 for viscous while L/D max is

4.4 for in-viscid.

1.4 Conclusion

After many analyses were performed on the aerodynamics of the vehicle, it turned out two

parameters were the deciding factors as to the success of the mission. First, the most important

parameter was the L/D max. Without a high enough L/D the entire mission is scrapped. The

vehicle shape as well as the viscous interaction drag governs the L/D and performance. There are

limitations to the max L/D achievable. A perfectly blunt flat plate with an infinitesimally small

22

nose radius has a L/D approaching infinity. However, this is both impractical for internal volume

as well as manufacturing capabilities. Also, viscous interaction is not taken into effect. Viscous

interaction can account for up to 70% of the total drag at high altitudes and at 30% at lower

altitudes . Therefore, it is very unreasonable to ignore viscous effect, especially when performing

an aero gravity assist mission around two planets. Analysis performed using a fixed L/D and

ignoring viscous effects return results significantly different from those with the considerations

of changing L/D and viscous interactions. In order to achieve a higher L/D, a more sophisticated

analysis would have to be performed on optimizing the vehicle shape.

If more time was permitted, the use of the tangent wedge method would improve the

aerodynamic results as well. The tangent wedge method is used for small angles of attack and the

flow field is determined by constructing a wedge that is tangent to a selected point on the body.

It assumes that the properties at the selected point are the same as those corresponding to the

point on the original body. The oblique shock theory is used to determine the points instead of

calculating the flow field around the body itself.

23

References

[1.1] Anderson, J.D. Fundamentals of Aerodynamics 2nd Edition, McGraw Hill, New York, 1991.

[1.2] Anderson, J.D., Hypersonic and High Temperature Gas Dynamics, McGraw Hill,

NewYork, 1989

[1.3] Clark, E.L. Trimmer, L.L., Equations and Charts for the Evaluation of the Hypersonic

Aerodynamic Characteristics of Lifting Configurations by the Newtonian Theory, Arnold

Engineering Development Center, Arnold Air Force Station, Tennessee, March 1964.

[1.4] Professor Schnieder’s Methods Report

24

2 Aeroheating – Brad Crosson

2.1 Introduction:

The primary purpose of the Aeroheating position was to provide the team with heat versus time

data. The shape that was chosen, a wedge, was easier to analyze than some of the more complex

shapes that are being launched today. A wedge was essentially the same as two blunt flat plates

placed at an angle to each other. This made calculating the heating forces much easier instead of

having odd geometric shapes to model.

For a wedge, the leeward side does not incur any heating; only the windward side needed to be

considered. This was true as long as the angle of attack that the wedge was flying at was at least

twice that of the half angle. This means that if the half angle was 6o, then the angle of attack

needed to be at least 12o so that the leeward side was shadowed. Also, the base of the wedge,

where the engines were, would not incur any heating effects from the aero-gravity-assist or

reentry. The engines were shadowed by the flap and the sides of the wedge. SPEAR was also

assumed to be at 200 K anytime it was outside of a planetary atmosphere, basically while it

traveled through space. These assumptions helped with the modeling of SPEAR and are more

clearly seen in the pictures in the Systems portion of the report.

A wedge shape was chosen because of previous examples and spacecraft currently in industry.

This shape had sound structural properties, simple aerodynamics properties and provided a nice

basic design which was complex enough to produce significant results, but not so simple that the

results would be meaningless.

25

Rocket launched space vehicles, such as the Shuttle orbiter, experience relatively little

aerodynamics heating during launch. For the shuttle, the heating at the stagnation point is two

orders of magnitude less during launch than during atmospheric entry from Reference (2-1).

The heat transfer rate was found using the free stream velocity, the free stream density, the

specific heat of the nose material, the nose radius, and the temperature at the stagnation point.

Many other variables had to be considered to obtain the previous variables. The other variables

that went into calculating the overall heating were: heat transfer rate, nose radius, base radius,

length of the craft, wedge half angle, overall mass, atmospheric conditions, radius of the planets,

angle of attack, edge of the atmosphere, heading angle, position, enthalpy ratio, viscosity,

emissivity of wall material, wall thickness, location of the center of gravity, C l and Cd, trim angle

for flap, and finding laminar/ turbulent boundary.

The nose was modeled as a solid block of UHTC while the TPS was made of SLA-561. This is

explored further in the TPS section. In the code, a total of ten points were unequally spread along

the length of the vehicle to determine the heating at various points. More points were placed

towards the nosetip because this section had greater changes in heating over the same time

interval. These points were used to model the different changes in temperature across the entire

vehicle.

2.2 Methods and Calculations:

26

The heatflux program was used in conjunction with the trajectories flown. The trajectory people

would fly an iteration while the heatflux code determined if the amount of heat exceeded the

maximum allowable. This was done during each iteration.

The basic heating rate equation came from Reference 2-1. This equation can be seen as Equation

below:

Eq

In Eq , C, N, and M are constants that were determined by the planetary properties while ρ and V

were the density and velocity respectively. The density and velocity constantly changed for each

of the different planets as SPEAR flew through different trajectories. These properties were

found using a combination of traj.f, trajsub.for, aerodat.f, aerotrim.for, the atmo.for functions and

solvereentry.for. N and M, known as the Tauber exponents, were 0.5 and 3.4 respectively for

both Mars and Venus. Mars and Venus both have CO2 atmospheres, so the same aeroheating

equations were used for both, only the density, velocity, etc. were different. For Earth, N and M

were 0.5 and 3.0 respectively. The Tauber exponents also change values based on whether the

flow was laminar or turbulent.

From Reference (2-2), for laminar flow for Earth, C = (1.83*10-8) rn-1/2 (1-gw) where rn is the nose

radius and gw is the ratio of the wall enthalpy (hw) to total enthalpy (ho). hw = cpwTw and the total

enthalpy is ho = ha +0.5 V2 where local enthalpy, ha, is much smaller than 0.5V2 and therefore

neglected. The heating equation for Earth can be seen as Equation below:

27

The equations for Mars and Venus are very similar just with a different C term and changed

Tauber exponents.

From this equation a great many ideas and equations need to be considered such as: stagnation

location, transition location, laminar or turbulent flow, inside or outside of the atmosphere, the

atmospheric properties, and the changing rate of heat at the different points along SPEAR. After

each of these was considered, the heating rates at each thermal point could be determined from

its flow condition and position downstream of the stagnation point. The equations that govern the

above concepts were put into the code used to compute the overall heat flux. The heat transfer to

the wing leading edges was not needed because of the shape of the spacecraft chosen.

The laminar/ turbulent transition location was found using Eq below where Re was the

Reynolds Number, M∞ was Mach infinity, ρ was the density, and Vinf was the velocity:

Eq

The atmosphere files for each planet governed the properties such as density, altitude of

usable atmosphere, and temperature. They also determined when SPEAR was actually in the

atmosphere. Heating was only affected while SPEAR was in the atmosphere and as soon as it

exited the atmosphere, the heating went back to 200 K.

Some general assumptions were that the skin friction effects on the pitching moment

were neglected as is explained in further detail in the Aerodynamics section. The side forces can

be assumed to be zero since the vehicle is symmetric. The L/D ratio becomes large for smaller

28

angles of attack and gets reduced with skin friction, nose bluntness, trim drag, and viscous

interaction.

2.3 Results:

When acceptable trajectories were found, the heating and heat flux could be more closely

examined. The final iteration results can be seen in the Appendix. The final iteration for Mars

can be seen as Figures 2.1 And 2.2, for Venus Figures 2.3 and 2.4, and for Earth 2.5 and 2.6.

The Mars and Venus figures were fairly similar. This was to be expected. For the final

iteration, the maximum heat flux for Mars was 2,781,560 J/m2*s and for Venus was 8,891,050

J/m2*s. The maximum wall temperature for Mars was 252 K and for Venus was 290 K. These

values were obtained at the stagnation points which were significantly larger than any of the

heating points downstream. This was also to be expected. These numbers are both acceptable and

reasonable. The heatflux and the wall temperature were also enough that the TPS would be able

to withstand the heating effects. This is further explored in the TPS section.

The Earth figures were similar in shape but differed in magnitude. The maximum

heatflux for Earth was 639,011 J/m2*s while the maximum wall temperature was 1,811 K. The

heatflux for Earth varied from an order of magnitude of 106 to 105 and the maximum wall

temperature, varied by over six times the maximum wall temperature of Venus. This was due to

the differences in the velocity and trajectory. Also, the way in which the heating was calculated

in the heatflux.for code did not compensate for radiative cooling for Mars and Venus. This will

be explained in the UHTC section of the Aeroheating report below. It can also be noted that the

29

second point along SPEAR produced the maximum heating and the maximum heatflux and not

the stagnation point.

From Reference (2-1), the heating rates and stagnation points for the Shuttle ranged from

470 to 930 W/cm2 at 8 km/s. The corresponding wall temperatures varied from 3200 to 3800 K

and were far beyond the radiative cooling capabilities of existing, non-ablating, heat shield

materials. It was found that for trans-atmospheric vehicles that as the total heating declined

dramatically with increasing acceleration. The heating load was inversely proportional to the

average acceleration and often greater heating was due to longer periods of exposure to turbulent

flow. The Tauber exponents are greater during turbulent flow than laminar which explains this

phenomenon.

The elements of aerothermodynamic heating are closely associated with the requirement

for low aerodynamic drag. To achieve low drag, the vehicle must be slender and have a relatively

sharp nose. Our vehicle is slender with a relatively sharp nose which greatly helped to reduce the

effects of heating.

2.4 UHTC Analysis:

The Ultra-High Temperature Ceramic, UHTC, made of ZrB2/SiC, HfB2/Sic or

ZrB2/SiC/C, was the material at the nose of SPEAR that confronted the highest heating

temperatures before the rest of the heat was differed to the TPS on the windward side. The data

on the UHTC was obtained from Reference (2-4) which was the most current, publicly available

information, which was released in 1969, over 35 years ago. The UHTC acted as a solid non-

ablating thermal protection system whose thickness was small compared to the surface distances

30

over which the heat transfer varied significantly. For a nose tip like this, it was better to consider

the nose tip as a solid heat sink instead of multiple heating points. The internal heat conduction

was large enough that it was approximated at a single temperature throughout the entire nose.

For blocks with sharp noses, this solid nosetip has heat transfer at the stagnation point ten times

greater than at the sides, Reference (2-3). The overall heat transfer to the block is not that high

with a sharper nose. The goal of the UHTC analysis was to find the minimum amount of TPS

needed to withstand the heating effects of reentry.

From Reference (2-5), wingless sharp body vehicles that utilize UHTC components at the

nose are optimum. Heavy UHTC components are not suitable for wings because they require

stiff structural support. UHTC at the nose minimizes the amount of structural support required,

the number of UHTC components, and moves the center of gravity forward.

The heating applied to the nose of SPEAR, was found using the Lumped Heating at Solid

Nosetip Model found in the Methods Handout. Eq below was the equation used to find the

amount of heat that a certain volume of UHTC would be able to withstand.

Eq

In Eq above, cp was the specific heat of the surface material, ρw was the density of the

surface material, V was the volume of solid nose tip, was the heat transfer rate, was the

radiation from fluid to the surface, ε was the emissivity of the surface, σ was the Stephan-

Boltzman constant, and Tw was the wall temperature. The density, emissivity, specific heat, and

31

Stephan - Boltzman term were held constant at 0.006 kg/cm3, 0.8 (unitless), 795 J/kg*K, and

5.669*10-12 W/cm2K4 respectively.

After some manipulation, dT was found to be equal to Eq below:

Eq

All of the variables were able to be determined except for the radiative cooling term.

From reference (2-2), radiative cooling is usually neglected for “reentry from LEO and becomes

significant mainly for reentry from escape velocity or perhaps high orbit.” Radiative cooling is

negligible only for velocities less than 10+ km/s. The entries into Mars and Venus would not be

from LEO but would be equal or exceed 10 km/s so radiative cooling was negligible . The

leeward side of the vehicle let heat escape from the UHTC, which decreased the maximum wall

temperature. At some temperature a steady state condition is reached where radiative cooling

from the rear and the sides of the block balances out the heat transfer at the stagnation point.

The temperature vs. time results from the code for the Mars final iteration can be seen in

Figure 2.7 in the Appendix. The green line in figures 2.7 to 2.9 represents the maximum

temperature that the UHTC can withstand; 3,033 K. In Figure 2.7, the maximum temperature

was found to be 1,129 K. This was within the ability of the UHTC to protect SPEAR. During this

trial, SPEAR was traveling at over 10 km/s which means that the radiative cooling term was

negligible as per Reference (2-2).

The results from the Venus Lumped Heating Model can be seen in the Appendix as

Figure 2.8. The results from the Earth lumped heating code can be seen in the Appendix as

32

Figure 2.9. From figures 2.8 and 2.9, Mars and Venus were within the abilities of the UHTC to

protect the vehicle. For the Earth’s heating effects, SPEAR was coming in on a much lower

trajectory (see MDO Earth for further analysis) than Mars and Venus which could then be

considered the same as a low earth orbit, LEO, entry. As stated earlier, if an object was entering

from a low trajectory, similar to that of a LEO entry, then the radiative heating effects would be

negligible. This can clearly be seen in Figure 2.9 in the Appendix where the UHTC provided

ample protection during Earth entry. The maximum temperature that the UHTC got up to for

Venus was 2,304 K. The maximum temperature that the UHTC got up to for Earth was 2,118 K

which was 915 K less than the maximum allowable temperature the UHTC is able to withstand.

A minimum volume of TPS was not able to be determined, but the TPS used was

adequate for the mission. The UHTC temperature was also found to be independent of the width,

because it was two-dimensional, thus neglecting the width.

2.5 Trade Studies:

Using close approximations to the final dimensions of SPEAR, trade studies were conducted to

find how varying different parameters affected the heating. These trade studies were done using

a Martian atmosphere with a complete iteration two trajectory. The studies were done using a

combination of the heatflux code and the SPSMars code to find trends.

The trajectory and the flight path angle were the two biggest factors in determining the heating of

the craft. The trajectory used to compute the following findings was done using the trajectory for

iteration two. Changing the flight path angle by 10% changed the maximum stagnation wall heat

flux by more than 80% and then the heat flux became too large. Changing the angle of attack by

33

55% changed the maximum stagnation wall heat flux by more than 35% and then became

untrimmable. Changing the length by 6% and changing the width by 20% did not significantly

affect the heating parameters. Changing the flap length by more than 30% did not significantly

alter the heating, but SPEAR became untrimmable when the flap became too large. When the

flap was approximately 15% of the overall length, SPEAR became untrimmable. Changing the

nose radius from almost a sharp leading edge to blunt nose changed the maximum stagnation

wall heat flux by over 75%. When the nose radius was too big SPEAR became untrimmable.

Figure 2.10 in the Appendix is a small cutout of a trade study.

The heat flux code gave outputs of the maximum stagnation wall heat flux, the wall

temperature, the time in the atmosphere, and the altitude profile. Figure 2.11 in the Appendix is a

sample plot of the wall heat flux vs. time. From Figure 2.11, the reason for the abrupt drop offs

at the beginning and end of the graph was due to the way the points were dispersed in the

atmosphere code. The atmosphere does not immediately stop, it trails off. In the code the

atmosphere has a definite ending point at which the code “sees” no more atmosphere which is

why it appears that the wall heat flux ends.

Figure 2.12 in the Appendix is of the wall temperature vs. time. This graph shows that after

SPEAR entered the atmosphere, it heated up as expected and maintained a fairly constant

temperature while it was inside the atmosphere. The graph does not show that when it left the

atmosphere, its wall temperature returned to 200 K. The graph was not extended out far enough

for this to be observed.

References 2-1 through 2-4 were used extensively as the primary source for the governing

equations. The equations in the references were adapted and implemented into the code.

34

2.6 Discussion/ Reflection:

The design chosen was an excellent one for the mission given. One advantage was that there was

no drag or heating from a swept leading edge. One disadvantage was that the nose was the width

of the vehicle, and this type of wide UHTC leading edge has not yet been successfully

manufactured (that we know about). Also there currently is a limit to the size of UHTC that can

be built in one piece. Also joints in the leading edge are problematic.

No design can ever be the best. There is always room for improvement. By the time a project is

ready to launch, new technologies have been discovered that make the technology on the ‘latest’

craft old and ready for replacement. In the case of Aeroheating, by the time a TPS or UHTC was

chosen and manufactured, another stronger, lighter, higher max wall temperature material may

have been made that would completely replace and outperform the one that was examined here.

One limiting factor in finding the best design was the length of time the iterative process took.

Also, the skill of the members and the effort put forth was another limiting factor. If we had

access to non-classified current materials, (government/ military technologies) it would have

greatly improved our results. If the TPS could withstand higher temperatures, we would have had

a larger range of angles of attack to fly at as well as being able to fly lower in the atmospheres

and therefore producing more lift. This would have helped immensely because more effort could

have been spent fine tuning our design instead of finding the small margin of acceptable ranges

at which SPEAR could adequately perform. Also, if more advanced propulsion systems were

available; our options would again have been expanded. With a more efficient and less bulky/

heavy propulsion system, it would have been possible to have a wider range of trimmable

35

locations and therefore greater mission flexibility. A better propulsion system could have also

allowed us to travel quicker and complete the mission faster and more easily match the required

planetary entrance and exit conditions.

If this project had continued I would have explored several different factors. I would have liked

to take a closer look at how why radiative cooling does not effect spacecrafts returning from

LEO but it is a significant factor when entering an atmosphere from higher orbits. I would also

have liked to examine how dependent the first downstream point was on the stagnation point.

Also learning about the UHTC production process, how it is made and what the constraints are

on its production and why may have provided useful information. That information would have

further constrained, and added another realistic parameter to our design. It would have been nice

to explore the effects of heating on a wide range of vehicle shapes. This would have provided a

lot of insight into ways to optimize the vehicle. With the complexity of getting a blunt flat plate

and a wedge to produce useful results, this seemed to be out of the question.

36

References

[2-1] Tauber, Michael E and Meness, Gene P, Aerothermodynamics of Transatmospheric

Vehicles

[2-2] Schneider, Steven P, Methods for Analysis of Preliminary Spacecraft Deisgns

[2-3] Anderson, J.D., Hypersonic and High Temperature Gas Dynamics

[2-4] Research and Development of refractory oxidation-resistant diborides, Part II, Volume V,

Thermal, Physical, Electrical, and Optical Properties, AFML (Air Force Material Labs)-TL-68-

190, 1969, DTIC citation AD-865321.

[2-5] Optimizing Hypersonic Sharp Body Concepts from a Thermal Protection System

Perspective, NASA Ames Research Center, AIAA paper 98, April 1998

37

3 Thermal Protection System – Robert MacDermott

3.1 Introduction:

The purpose of the TPS on any vehicle is to protect the vehicle from the high temperatures

associated with atmospheric re-entry and hypersonic flight. Without TPS any vehicle that enters

the atmosphere will burn up. TPS is a complex issue. The aerodynamics, aeroheating, and

trajectories determine the strength and duration of the heating. These three areas are very

complicated and have many, many factors that affected the results of the TPS analysis. The TPS

analysis itself is also complicated. Determining what material to use, and how much of that

material, comes down to a large system of thermodynamics problems.

There are two major varieties of TPS, ablating and reusable. Ablating TPS, when heated to a

certain temperature, sublimates and material is removed. The removal of this heated material

from the system removes energy and therefore keeps the temperature from rising as high as it

normally would. Reusable TPS comes in the form of an insulator. A good example of this

would be the space shuttle tiles. They are silica ceramic with a low thermal conductivity. The

outermost part of the tiles heats up, but that heat is not fully transferred to the inner parts of the

tile, allowing the understructure to be kept at a lower, more reasonable, temperature.

3.2 SODDIT:

38

Sandia One-Dimensional Direct and Indirect Thermal (SODDIT), reference 3.1 and 3.2,

is the name of the code used to model the TPS. SODDIT uses a one dimensional control

volume to solve the thermodynamics problem presented. It was written in Fortran by the Sandia

Laboratories, and no modifications have been made to this program.

SODDIT requires data to be stored in input files. These files are saved in the format:

filename.inp. These files contain up to 11 distinct blocks of information that SODDIT requires

to perform its operations. See table 3.1 for what each block does.

Table 3.1 : SODDIT block Descriptions

Block Description

1 Control Flags

2 Title Records

3 Print Times, Increments, and Thermocouple depths

4 General Problem Constraints

5 Material Property Data

6 Nodal and Element Data

7 Boundary Condition Constants

8 Front Face (x=0) Boundary Conditions

9 Back Face (x=0) Boundary Conditions

10 Gas Enthalpy Data

11 Energy Generation Rate Constants

Block 1, the control flags, tells SODDIT how it is going to set up the problem. There are

80 different control flags that can be used. For this analysis, only 4 needed to be used. Flag 2

was used to determine if the current run was to have automatic node genearation or be a restart

39

run with data taken from a pervious run. When Flag 2 was set to 0, SODDIT uses automatic

node generation. When Flag 2 was set to 3 then data from the SODDIT output file was put into

the new input file for node generation. Flag 4 was set to either 0 or 3 depending on if ablation

was desired or not. Flag 4 was set to 1 so that a _plt.txt file was outputted. This file format put

the output data into a more plot friendly format. Flag 16 told SODDIT that all calculation were

to be performed in consistent SI units. This prevented the conversions that are necessary when

dealing with English units, such as the conversions between slugs, lbm, and lbf.

Table 3.2 Control Flag values uses and descriptions

Flag Values

2 0→ automatic nodes , 3 → user defined nodes

4 0 → no ablation , 3 → ablation

5 1 → gives filename_plt.txt as output

16 1 → All calculation assumed to be in SI

Block 2 is set up as a description of what data is inputted into the system. SODDIT does

not actually use any of the data in this section. It instead is intended for the user, so that the

output files can be tracked and differentiated from one another.

Block 3 is used to specify a maximum time and a time interval.

Block 4 sets up the general problem constraints. These were not varied and included elements

like computation time steps, the maximum temperature step in a single node for a single time

step, and the Stefan-Boltzman constant.

Block 5 is the material properties section. This defines the material properties for each

material used for the TPS. For SPEAR (Spacecraft for the Purpose of Exo-Atmospheric

Rendezvous) there were 3 layers; an ablator, an insulator, and the SPEAR skin. Each material

40

was allotted its own section in block 5. The code used the material properties of density, heat of

formation, specific heat, thermal conductivity, emitance, absorption, and heat of ablation. The

materials used were found in reference 3.3.

Block 6 deals with the node and element data. For a normal run, not a reinitialization

run, the initial temperature for the nodes is set in this section. For the basic case T initial = 200 K.

This temperature was chosen based on the assumption that the SPEAR would spend long periods

of time in interplanetary travel and any residual heat due to atmospheric entry would have had

ample time to dissipate over those long time intervals. Block 6 was also where the number of

nodes in each layer of the material was defined. Nodes are defined as the individual points

inside each material layer for which SODDIT runs an analysis. Each material layer can have a

different number of nodes. At the same time this was where the thickness of each layer was

defined. Each layer could also have a different thickness. For an ablator, the depth of each node

would change as the material ablated. For an insulator, the depth of each node would remain

constant. For a reinitialization run, each node was assigned a material, thickness, and

temperature. The easiest way to do this was to take the section of the filename_out.txt file that

was specifically formatted for a SODDIT restart.

Block 7 is where the boundary conditions are defined. For the purpose of this project, the

outer boundary condition was defined as the heat flux as a function of time. This was given in a

heat flux file, filename.qw. This file came from the trajectory code.

Block 8 was the inner boundary condition. For this case it was set as perfectly insulated. This

was not what would happen in reality, however, it leads to a more conservative estimate. The

estimate is conservative because if the back wall is looked at, when it is perfectly insulated, the

41

final temperature is higher than if heat was allowed to pass through it into the interior of the

SPEAR.

Blocks 9, 10, and 11 were not needed for this type of analysis and were therefore left out

of the input file.

There are a couple of things that were worthy of noting with the SODDIT program. First

is that if ablation is desired, the outer temperature cannot be dropped below the ablation

temperature. When this happens, the SODDIT code encounters an error and all data at and past

the point where ablation stops is corrupted. To fix this, the code needs to be run up to the time

step before the outer temperature drops below the ablation temperature, and then after that run

has been completed, create a new input file with the reinitialization criteria and start the run

again from the time step where the temperature dropped below the ablation temperature. There

was also a problem with high node to thickness density. When there are too many nodes in a

very small thickness, the data became unreliable. To prevent this one simply has to use a

number of nodes that is not excessive when compared to the thickness of the layer.

3.3 Validation of SODDIT:

To ensure that SODDIT was actually accurately modeling the material response to the heating

data, a validation was performed. By solving the basic heat equation taken from reference 3.4,

setting the boundary conditions to something SODDIT could handle, and comparing the solution

to the output from SODDIT, it was possible to confirm that SODDIT works well for heat

conduction.

42

Equation 3.1

Equation 3.2

The boundary conditions were as follows: one end of the bar was held at a constant temperature,

the other end was considered to be perfectly insulated, and that at the initial time, the bar was at a

uniform constant temperature. The solution to this problem was found in reference 3.5.

Equation 3.3

Equation 3.4

Equation 3.5

For the test case the temperature at x=0 was held at 273.15 K and x=L was considered to be

perfectly insulated. The initial condition for the bar was set as f(x) = 0 K. This heat equation

problem with the specified boundary conditions was solved in Matlab. Then an input file was

created for SODDIT that had the same conditions, material properties, and thicknesses.

SODDIT was run and the results were graphed in Matlab. The results are shown in figure 3.1

and figure 3.2 below. The data was as expected. At the point x=0, the temperature is being held

at the 273.15K value for both time periods. As the one looks deeper into the thickness, the

43

temperature drops so it is closer to that of the initial condition of the bar, T=0K. At t=0sec, the

entire bar was at T=0K, then at t=35 sec, the bar had begun to heat up. At t=75 sec the bar had

become progressively warmer. The SODDIT data points followed the expected trend and were

only off by only a small percentage. Given the SODDIT was built for ablation problems and was

many times more complex that the Matlab heat equation code, this is well within an acceptable

range.

0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.020

50

100

150

200

250

300

depth in meters

Tem

pera

ture

in K

elvi

n

depth vs. Temp for t=35 seconds

Heat EquationSoddit data points

Figure 3.1 Heat Equation and SODDIT Data for time equals 35 seconds

44

0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.020

50

100

150

200

250

300

depth in meters

Tem

pera

ture

in K

elvi

ndepth vs. Temp for t=75 seconds

Heat EquationSoddit data points

Figure 3.2 Heat Equation and SODDIT Data for Time equals 75 seconds

3.4 Matlab SODDIT Interaction:

The major problem with the SODDIT program was that the input file needed to be

perfectly formatted for the code to run. The input file was very long and complicated to build,

and to do so for each iteration would be very time consuming. A solution to this was created by

one Gregory Heckler who created a SODDIT/Matlab interface program in Matlab. His program

used a system of functions to create an input file, run SODDIT, and output the data in a format

Matlab could use. The functions opened the heatflux.qw file that was outputted by the trajectory

code and created block 7, took inputs from other files for blocks 5 and 6, and then assigned the

remaining blocks a fixed set of parameters that was not varied. His code also allowed for a

sweep of various thicknesses for various heating points. A validation of his code was preformed

by creating an input files by hand and running SODDIT and then inputting the same material

properties, thicknesses, and heating file into his code and letting it run. The results were that the

45

two matched up perfectly. This meant that the Heckler code did in fact properly input and run

the SODDIT code.

By no means was the Heckler code perfect. While it did give technically correct data, it

was formulated for a different problem. The problem that the Heckler code was built for had

only a single atmospheric reentry. Because of this the Heckler code looks for only a lower

boundary temperature over a range of thicknesses. When looking at runs for a single thickness,

it was noticed that for any thickness of ablative TPS greater than the actual amount ablated, the

amount ablated remained constant. For example, when the code was run for a heating file and a

thickness of 5 cm was used, 1 cm of TPS ablated away. When the same heating file was used

but thickness was 10 cm or 2 cm, the ablation remained at 1 cm. Given this data, and the fact

that the SPEAR mission had 3 different atmospheric reentries, the Heckler code was not

efficient.

Also, the Heckler code outputs were deemed to be too “busy” to be easily evaluated. So

a simpler output system was created. The file macd_soddit_run.m was created to allow for

easily readable data for each heating point. Furthermore, the Heckler Code input system was

modified to allow for easy changing of material properties, thickness, maximum times, heating

files, and which specific heating point it looked at. For the output files, macd_stuff1.m was the

file that plotted the material thickness vs. time and the temperature between each layer vs. time.

These plots displayed the necessary data to observe what thicknesses of TPS were required to

meet the criteria set for the SPEAR.

The macd_soddit_run.m system of files ran the SODDIT code for this project. The

macd_soddit_run.m file contains all the necessary inputs to control SODDIT. It is not a

function, it is a script. The purpose of the macd_soddit_run.m script is to make changing

46

parameters for different SODDIT runs as easy as possible. The script is broken down into three

sections. The first section is the heating file section. Here the heating file is named, and

maximum run time is taken from the heating file, and the heating point that one wants to analyze

is assigned. The second section is the material section. In the material section the ablator,

insulator, and the SPEAR skin are defined. The macd_soddit_run.m is limited in the number of

materials that can be entered. Because of the way it was written, only three materials can be

used. For each material layer needs to have a material file assigned to it. This material file tells

SODDIT the density, heat of formation, specific heat, thermal conductivity, emitance,

absorption, and (if needed) heat of ablation for that material layer. The material is then assigned

a thickness, flagged as an ablator or non-ablator, and assigned a number of nodes. This data will

then be transferred to soddit_control.m. The third and final section simply turns ablation on or

off and calls soddit_control.m. This system of codes has been dubbed the MacDermott code.

Earlier it was mentioned that the Heckler code was “busy”. This was because of the

“sweep” and that the Heckler code looked at all ten heating points. (It should be noted that there

are ten heating points because that is how many point the aeroheating code looks at. That

number is arbitrary and completely at the discretion of the trajectory/aeroheating group.) The

sweep variable in the Heckler code allowed for multiple thicknesses to be plotted on the same

graph. This was confusing. To deal with this the macd_soddit_run.m system does not use the

sweep variable. It is set to zero and left at that. Since it was hard coded into the Heckler code, it

could not be removed entirely, and thus remains, but it is not used. Instead of looking at various

thicknesses, a single thickness is looked at graphically, and then the user is able to determine a

more appropriate thickness value to go to.

47

The Heckler code also used 10 heating points on every plot, this made for very busy and not

easily readable plots. To fix this, the current system looks at a single point, heating point two,

instead. Heating point two is the first heating point after the stagnation point. It also has the

highest heating, and therefore the most ablation. Therefore any TPS layering that works for

heating point two will also work, and be conservative for all the heating points downstream. The

idea of looking at two or three heating points and finding thickness that would work for them

was considered. Instead of an initial uniform thickness across the entire lower surface, this

would have split the lower surface into two or three sections, each with a decreasing thickness.

This design was tossed back and forth between TPS and systems. Systems decided that it would

be too complicated to model and therefore the decision was made to have a uniform initial

thickness over the entire bottom surface instead of several sections of various thicknesses.

Another innovation of the MacDermott code is the single heating point plots. The file

macd_stuff1.m takes the last run of the SODDIT code and make a plot of the thickness history of

each material layer vs. time and the temperature between each material layer vs. time. This

allows the user to quickly see how much material has been ablated, when that ablation started,

when the code encountered an error, and if the inner wall has reached its maximum temperature

yet.

So, the MacDermott code, while it has the ability to look at several points, prefers to look at a

single point. It will allow the user to change the materials, thicknesses, nodes, ablation, heating

file, and max run time all from a single file. For each heating point looked at it will output a

separate plot with both thickness and temperature data. It will do this quickly and without

running multiple unnecessary runs for thickness that need not be used.

These modifications allow for a TPS iteration cycle to be easily implemented.

48

3.5 TPS iteration cycle:

The iterative process for the TPS was a least a six step process. This means that for each

Design iteration, there were at least 6 runs of the TPS code. The process started with a run for

each planet with the heating files given for that iteration. The ablation for each planet is added to

together and then multiplied by a safety factor of 20%. Then the full ablative TPS, with the

safety factor added, is run for the Mars trajectory. The Mars ablation is subtracted from the

ablator thickness, and the Venus trajectory is run. The Venus ablation is subtracted from the

ablator thickness and the Earth trajectory is run. These three runs are done in series to make sure

that the thicknesses and safety factor indeed work for the heating files and that the maximum

wall temperature is not exceeded. The maximum wall temperature was set at 350 Kelvin due to

the requirement of some of the internal components that would cease to operate if exposed to

temperature higher than 350 Kelvin.

The first set of steps find the ablation for each planet and the maximum time the run can

encompass. To do this the initial ablative TPS thickness is set to a large number and the max

time is set to the maximum time the heating file runs. When the code is run for a heating file, by

looking at the plots, the user can find the amount of ablation for the run, and the time until the

code encounters an error. This data is then saved for each planet. For example, if for the Mars

heating file the user found that there was 1 cm of ablation and the code ran for 400 seconds

before encountering an error, then the user would save the 1 cm and the 400 seconds for later use

and then move onto the Venus heating file. Assuming they found 2 cm ablation for Venus and a

49

run time of 360 seconds, and then 3 cm ablation and a run time of 610 seconds for the Earth

heating file. This would complete the first half of the iteration. The user would then know that

this iteration should use about 6 cm of ablation.

The safely factor of 20% was initially decided upon. Later in the iterations the safety

factor was bumped up to 50% because of some uncertainty that surfaced. Typically the code

only ran for the first 20-25% of the Earth heating file. Due to this uncertainty, and the desire not

to have the SPEAR burn up due to a lack of a sufficient safety factor, the 50% safety factor was

chosen.

The second half of the iteration validates the choices the user made. The user starts at

Mars with 9cm of ablator and an insulator of 1 cm with a max time of 400 seconds. The Mars

run says that 1 cm is ablated and so the final for Mars becomes 8 cm of ablator left and a wall

temperature of 206 Kelvin. The Venus initial conditions are 8cm of ablator and 1 cm of insulator

and a run of 360 seconds. The results are that 2 cm are ablated and so 6cm of ablator was left

and a wall temperature of 232 Kelvin. The final test is for earth with the initial conditions of 6

cm ablator and 1 cm of insulator and a 610 second run. During the earth run 3 cm is ablated,

leaving the final answer of 3 cm of TPS left and a wall temperature of 255 Kelvin. There is still

a safety factor for the ablator and the wall temperature is below the 350 Kelvin constraint and so

the user finishes the iteration and reports that there should b 9 cm of the ablator and 1 cm of the

insulator for that iteration. Below in table 3.3, the numbers from this sample iteration have been

listed. Please not this is a SAMPLE iteration only, not actual data from any part of this project.

Table 3.3 Sample TPS iteration table (NOT actual iteration)

Step Ablator Depth Insulator Depth ablation T skin

Mars 1 t1=5cm t2=1cm tabl=1cm T=222K

50

Venus 1 t1=5cm t2=1cm tabl=2cm T=245K

Earth 1 t1=5cm t2=1cm tabl=3cm T=261K

First Half of

Iteration

t1=9cm N/A N/A N/A

Mars 2 t1=9cm t2=1cm tabl=1cm T=206K

Venus 2 t1=8cm t2=1cm tabl=2cm T=232K

Earth 2 t1=6cm t2=1cm tabl=3cm T=255K

End of

Iteration

taccepted=3cm t2=1cm N/A N/A

Had the Twall value been greater than the allowable value at any step, then the Insulator

thickness would have had to been increased. This would not have affected any of the steps

before the insulator increase because the only possible effect on temperature would have been a

decrease.

3.6 Material Selection:

The selection of the materials was a little difficult. The SHARP skin was already

determined by the structures analysis, however, the ablator and the insulation still needed to be

chosen. To do this, an analysis of the different materials was needed. The procedure was very

simple. Thickness of layer, initial conditions, and heating file were held constant, only the

material was changed.

51

The ablator was looked at first. There were 5 candidates: SLA-561v, Avcoat 5026,

ESA-3560, MA-25S, and the Elastomeric Ablator. Data for ESA-3560, MA-25s and the

Elastomeric Ablator came from reference 3.3. Data for SLA-561v and Avcoat 5026 came from

reference 3.7. The information needed for each source was the density, heat of formation,

specific heat, thermal conductivity, emitance, absorption, and heat of ablation. This data was

formatted to fit the block 5 requirements of SODDIT. SLA-561v and Avcoat 5026 already were

in the correct format, having been used by a previous senior design group. The other three

ablators had to be formatted to fit the block 5 specifications. The block 5 format requires various

values of the specific heat, thermal conductivity, emitance, and absorption at different reference

temperatures. However, reference 3.3 did not always have the data in that nice format. Instead it

gave data at various temperature that did not always match. To fix this, the data was put into an

excel spread sheet. Once in excel the data was converted from English to metric units. Then the

data was plotted and a second order polynomial was fit to the data. That polynomial was then

used to get a reasonable approximation of the data from reference 3.3. The numbers from the

polynomial fit are the numbers that were used in the block 5 formatted material files.

The initial conditions for this test were as follows: a 61 second heating run through a Venus

trajectory with an ablator thickness of 5 cm at heating point 2. The time length was set at 61

seconds because that was the length of the only heating file available when the tests were started.

The thickness of 5 cm and heating point 2 were arbitrary and do not matter as long as they are

the same for every test. The first round of results can be see in table 3.4.

Table 3.4 Initial run for 5 ablators

Ablator Time of Run Ablation

SLA-561v 61 sec 0.5 cm

52

Avcoat 5026 61 sec 0.6 cm

ESA-3560 61 sec 1.8 cm

MA-25S 37 sec 5 cm

Elastomeric Ablator 61 sec 0 cm

What these results said was that the MA-25s was the worst ablator. It did not last through

the entire test. The other four ablators did. A layer of MA-25S would have to be 15 times

thicker than a layer of SLA-561v to do the same job. Since the MA-25S’s density is not 1/15

that of the other ablators, it was summarily dismissed as a candidate for the SPEAR ablator.

The results also said that it took 3 or 4 times the thickness of ESA-3560 to do the job of

the Avcoat 5026 or the SLA-561v. Since the density of the ESA-3560 is on par with the

densities of Avcoat 5026 and SLA-561v it was also deemed to be inferior and was no longer in

consideration for the SPEAR ablator.

The Elastomeric Ablator looked to be the best; however, something did not seem right

with the results. The temperature of ablation that was inputted into the material files was 3330

Kelvin. This was entirely too hot. The activation temperature for oxidation was assumed to be

the temperature of ablation. This was a faulty assumption and renders any calculation with the

Elastomeric Ablator to be invalid. For this reason, and since there was no way to find an actual

temperature of ablation, the Elastomeric Ablator was rejected as a possible ablator for the

SPEAR.

53

This narrowed the field down to two ablators. Avcoat 5026 ablated slightly more and has a

higher density, while SLA-561v had slightly better ablation and a lower density. The choice

based upon these two criteria would go to the SLA-561v, however, there was also the factor of

heat conduction to look at. To look at the heat conduction, the thickness had to be dropped so

that the temperature under the ablator could be seen. The thickness was dropped to 1 cm and the

SODDIT code was run again for those two ablators. The results are listed in table 3.5.

Table 3.5 Change in temperature under ablators

Ablator

SLA-561v 60K

Avcoat 5026 150K

For the same initial thickness, the SLA-561 had a smaller temperature change directly

beneath the ablator. This was done using the same Venus trajectory file, time of run, and heating

point, just a different intial thickness. Since Avcoat 5026 has a larger density, ablated slightly

more for the same heating, and had a greater thermal conduction for the same thickness, then it

was also rejected, and the SLA-561v was accepted as the best of the ablators that were looked at.

Below in Table 3.6 the various material properties of the ablators are listed.

Table 3.6 Material properties of the 5 ablators

Ablator Density

(Kg/m^3)

Temperature

of ablation (K)

Heat of

Ablation (J/Kg)

Average K

(W/K-m)

SLA-561v 480 588 5.41e7 2.13e-1

Avcoat 5026 528 752 2.38e7 2.42e-1

54

ESA-3560 480 716 1.35e7 9.65e-1

MA-25S 400 783 0.32e7 0.87e-1

Elastomeric

Ablator

224 3330 0.88e7 0.54e-1

Looking at table 3.6 there are several things that can be observed. Those ablators with

the largest heat of ablation lasted the longest. What this means is that it took more energy to

cause them to ablate and therefore that energy was not able to penetrate into the lower layers of

the TPS. One would think that thermal conductivity would also be very important, but that was

not so. ESA-3560 has a largest thermal conductivity, and it performed poorly. However, MA-

25S has the lowest thermal conductivity and it also performed poorly. So when looking for an

ablator, it was determined that one should try to find the highest heat of ablation value possible

and balance that with the lowest density possible. Low thermal conductivity is also desirable.

The other material that needed to be looked at was the insulator. The choice was made to

go with a Carbon Carbon flake, more commonly referred to as the Carbon Foam. The Carbon

Foam was found in reference 3.6. It was recommended by the David W. Kuntz of Sandia

National Laboratories, the same Sandia that created the SODDIT code. It was designed as an

insulator and will not cause pressure problems due to out gassing. For these reasons it was

decided that the Carbon Foam would be used for the insulator.

3.7 Optimization Program:

55

Due to the nature of the Aerospace industry, where mass is king, a way of optimizing the mass of

the TPS was needed. For any optimization problem, there needs to be an objective. In this case,

that objective was to minimize weight. To analyze the objective, there needs to be a

mathematical representation of that objective, called the objective function. The objective

function must describe the objective using variable that are relevant to the problem and that can

be controlled. These are called variable of interest. For the TPS, the variables of interest were

the thickness of the ablator and the thickness of the insulator. Since the weight is the objective,

the objective function would be the mass of the TPS expressed in terms of the thickness of the

ablator and the thickness of the insulator. This function was set as mass of the TPS is equal to

the summation of the density of the layer times the volume of the layer. The area over which the

ablator and the insulator are applied are to be applied are the same, and so they can be left out of

the equation. Therefore the objective function is:

Equation 3.6

The obvious answer would be that both the thicknesses should be zero, and that would be the

optimum solution. This was unacceptable because of the constraints that the SPEAR skin cannot

go above 350 Kelvin and that there needs to be enough ablator for the entire run. Therefore the

two constraints were added to the problem. The MacDermott Code was modified to enable

macd_soddit_run.m to output the maximum time of the run, the maximum temperature of the

SPEAR skin, and the amount of ablation observed. This also required a modification of the

soddit_control.m file. These two files were renamed optim_macd_soddit_run.m and

optim_soddit_control.m respectively.

56

Matlab has several optimization codes built into it. The function fmincon is the one that was

used. The function fmincon takes the objective function, aae450fun.m, and the constraints,

aae450con.m, and then uses sequential quadratic programming (SQP) to try and solve for a

minimum. The main reason that fmincon was used is that it can deal with non-linear constraints

by creating the constraint function aae450con.m.

There are 5 main files in the optimization code. Most of the files hav already been

mentioned. The following is a brief description of how they interact. aae450proj.m is the master

script file. It tells the other functions what heating file, maximum time, and heating point to use.

It also calls sets a starting point, sets up options for fmincon, sets boundaries, and calls fmincon.

aae450fun.m contains the objective function. That is all it does. aae450con.m finds the

constraints. It does this by calling optim_macd_soddit_run.m, which outputs the maximum time,

temperature, and ablation for that run. optim_macd_soddit_run.m reads a global variable set in

aae450proj.m for the heating point, heating file, and max time allotted for the run. The rest of

optim_macd_soddit_run.m works just like macd_soddit_run.m. It does call

optim_soddit_control.m. optim_soddit_control.m works just like soddit_control.m only there is

no plot and this is where the maximum time, temperature, and ablation for that run are found.

3.8 Iterations

Starting with iteration zero, there was no real understanding of what to expect. The

iteration started with very large initial ablator layers and these layers were adjusted to a more

appropriate size as data became available. The end result of iteration zero was that there was

57

hardly any ablation used. Below, table 3.7, shows the various ablation amounts for each planet,

the safety factor use, the final ablator thickness, and the insulator thickness that was accepted.

Table 3.7 Iteration ablation and thickness data

Iteration Mars

Ablation

Venus

Ablation

Earth

Ablation

Safety

Factor

Ablator

Thickness

Insulator

Thickness

Zero 0.35 cm 0.50 cm 0.25 cm 20% 1.35 cm 1 cm

One 1.10 cm 0.40 cm 0.20 cm 20% 1.70 cm 1 cm

Two 0.30 cm 0.50 cm 0.30 cm 20% 2.00 cm 2 cm

Three N/A 0.35 cm N/A N/A N/A N/A

Four 0.70 cm 0.06 cm* 0.50 cm 20% 1.45 cm 0.25 cm

Five 0.25 cm 0.08 cm* 0.20 cm 50% 1.50 cm 1 cm

Six 0.25 cm 0.25 cm 0.20 cm N/A 1.50 cm 1 cm

* ablation was off by almost an order of magnitude, for iteration five was replaced by 0.55cm estimation

Iteration one and two ran very smoothly. The Mars ablation shot way up in iteration one. This

was due to major change in the trajectory that was run for mars. All in all the amount of ablator

didn’t change very much. From iteration zero to iteration one the ablator thickness changed by

25%. From iteration one to iteration two the ablator thickness only changed by 17%. The

insulator thickness was doubled to try and keep the Spear Skin temperature from changing. It

was then noted that any additional thickness past the amount needed to get he job done is just

extra weight added to the system. From that point on the goal was to use only as much insulation

as needed.

58

Below in figure 3.3 one can see the TPS thickness vs. time for heating point two on the Venus

run for iteration 2 and in figure 3.4 can be seen. One major thing that should be noticed is that as

the heating did not really begin until about 75 seconds in the run. Then the surface of the ablator

did not reach the temperature of ablation for another 50 seconds. Ablation then took place for

about 250 seconds, at which point SODDIT encountered an error and so the run was stopped.

Looking at the two figures it is easy to see how the thick ablation layer affects the temperature

distribution. Only 0.5 cm of ablative TPS was used during the run. Due to the safety factor and

the fact that the SPEAR still had an Earth reentry to complete, it had considerably more TPS than

was necessary. This acted like an extra insulator. The bottom of the TPS barely got above 300

Kelvin and the bottom of the insulator was raised a mere 2 Kelvin. This was one of the major

factors in realizing that less insulation was needed on the SPEAR.

0 50 100 150 200 250 300 3500

0.5

1

1.5

2

2.5

3

3.5

4

4.5

Time (sec)

dept

h (c

m)

SLA-561V.m Ablation at heating point 2 for tabl = 0.017 and tinslator = 0.02

Original DepthAblation DepthCarbon Carbon FoamGraphite-Carbon skin

Figure 3.3 TPS depths vs. time

59

0 50 100 150 200 250 300 350 400150

200

250

300

350

400

450

500

550

600

Time (sec)

Tem

p (K

)

SLA-561V.m Temperature at heating point 2 for tabl = 0.017 and tinslator = 0.02

Outer LayerBetween Ablator and Carbon FoamBetween Carbon Foam and Composite skinInside wall of shipMax temp of inner wall

Figure 3.4 Temperature at depth vs. time

When it came to iteration three there was a complete disaster. Both the earth and the

mars analysis failed, and so no data was available from this run. The next two iterations were

baffling. Mars and Earth behaved as expected. Venus did not. All of a sudden, and for no

apparent reason, the ablation dropped off by 85%. Having ablation of only 0.35 cm seemed low,

but having an ablation of 6 mm seemed ludicrous. To see what was going on, a plot of heat flux

and ablation rate vs. time was made. The two plots can be seen as figure 3.5 and figure 3.6.

60

0 50 100 150 200 250 300 350 400 4500

1

2

3

4

5x 10

-6 Venus Iteration 4 Ablation Rate and Heat Flux vs. Time

time (sec)

Abl

atio

n R

ate

(m/s

ec)

0 50 100 150 200 250 300 350 400 450-2

0

2

4

6

8x 10

6

Hea

t Flu

x (W

/m2 )

Figure 3.5 rates for iteration 4

0 50 100 150 200 250 300 350 4000

1

2

3

4

5

6x 10

-6 Venus Iteration 5 Ablation Rate and Heat Flux vs. Time

time (sec)

Abl

atio

n R

ate

(m/s

ec)

0 50 100 150 200 250 300 350 400-2

0

2

4

6

8

10x 10

6

Hea

t Flu

x (W

/m2 )

Figure 3.6 rates for iteration 5

From these two plots it was possible to see that the ablation rate and the heat flux actually

follow one another closely. The y labels are slightly off, but both start at zero at time zero, and

peak at relatively the same time. The question became, then why was the ablation so low. To try

61

and find the answer, a plot of the heat flux at heating point two for various iterations was made.

This is shown in figure 3.7.

0 100 200 300 400 500 600-2

0

2

4

6

8

10

12x 10

5

time (sec)

Hea

t Flu

x (W

/m2 )

Heat Flux vs. time for various iterations

Iteration 2Iteration 3Iteration 4Iteration 5Iteration 6

Figure 3.7 Heat flux vs. time for iterations 2-6

What was learned from looking figure 3.7 was that the ablation rates were possibly correct.

Iteration 2 had the largest heat flux running all the way up to 12e5 W/m^2. Iteration 3 and 6 had

slightly lower levels. This also corresponds to their lower ablations, 0.35 cm and 0.25 cm

respectively. Iterations 4 and 5, had the lowest two heat flux magnitudes. They also had the

low, low ablation values that were thought to be faulty. Given the above 3 figures, the ablations

was more than likely correct. However, at the time, before above analysis had been done, the

small ablation number were seen as an error somewhere in the running of the code. To deal with

this, the largest historical value of Venus ablation was used to compensate for possible code

errors. As it turned out, there was no need for this, however it is better to be safe and have a

successful mission than to underestimate and fail.

62

Iteration 6 was performed as a checking iteration. Instead of modifying the TPS based on

the heating files, the TPS was tested to see if it would work for the newer heating files. The

results were that the base line ablation tests worked. Since this was to be the last iteration

preformed then a restart was attempted on each of the three planetary trajectories.

Figure 3.8 Mars Temp History Iteration 6

Above, in figure 3.8 one can see the full temperature history for the iteration 6 run

through the Martian atmosphere and the subsequent exit into space. The blue line is the

temperature of the outer surface of the ablator. It rises sharply as the SPEAR enters the Martian

atmosphere and then holds once it reaches the ablation temperature for SLA-561v of 588 Kelvin.

When it dropped off sharply again, that is where the ablation stopped, SODDIT encountered and

error, the run had to be stopped, and then started again. After ablation stopped, the outermost

layer (top of the ablator) immediately started to cool. The temperature at the top of the insulator

(pink line) was raised for short time and then started to cool down. The Spear Skin (green line)

temperature continued to rise for quite some time, almost 1500 seconds (25 minutes). However

63

the increase in temperature was only around 23% and the Spear Skin never came close to the 350

Kelvin constraint.

Figure 3.9 Venus Temp History Iteration 6

The same process was repeated for Venus. The data can be seen above in figure 3.9. The

Venus runs followed the same format as the Mars run. The Top of the ablator heated rapidly

when it came into contact with the Venusian atmosphere. It hit a plateau while ablating and then

it cooled rapidly once it has left the atmosphere. The top of the insulator did the same here as in

the Mars run, a little excess heating, but then it cooled rapidly as well. The SPEAR skin

temperature took much longer to reach the maximum temperature, which once again was 23% of

the initial temperature at the time of the reinitialization. It took 1000 seconds (20 minutes) for

the SPEAR skin temperature to reach its maximum value.

The very same process was tried on the Earth run. The results could not have been more

confusing. The Earth run terminated just like all the others had. The earthiter6_out.txt file had

the reinitialization table, just as expected. The heat flux after SODDIT encountered the error

64

was negative, also as expected. However, it was not constant, like the other heating files had

been. It was also 3 orders of magnitude smaller than the Mars or Venus heat flux numbers had

been. For some reason, when those numbers were entered into SODDIT, in the exact same

manner as the numbers for Mars and Venus had been entered, SODDIT kept increasing the

temperature to above the ablation temperature and then encountering another error. The only

way that SODDIT could do this is to increase the temperature while being given a negative heat

flux. This means that energy was being taken out of the system, and yet the temperature of the

system was rising. Much like if someone where to take a hot steel bar, submerge it into cold

water and then the surface temperature of the steel began to rise. This item caused much

confusion, and there has not been a satisfactory answer proposed.

3.9 Results

When the project was started, the expectation was that the TPS system would be a large

portion of the mass and possibly be the prohibitive factor of the mission. The results from the 6

iterations that were run told a very different tale. According to the data, the TPS was a very thin

coating on the SPEAR. This was not what was expected at all. For a very reasonable, and

incredibly thin, thickness, the SLA-561v and the Carbon Foam were able to protect the SPEAR

from the heat of atmospheric entry. There are some caviots.

The data that was collected is only as good as the assumptions that are used to make it.

The SODDIT code was the only method used to analyze the TPS. Therefore any weakness of

SODDIT is a weakness of this analysis. SODDIT used one dimensional control volumes,

whereas engineering deals with a three dimensional world. There will be some error from this.

65

SODDIT also relies on use defined inputs. The block 7 boundary condition are only as good as

the trajectory and aeroheating codes that made them. The Earth data was a constant thorn in the

side. Thinking logically about earth reentry, there should be a lot of TPS needed, however the

analysis does not show this. This has caused some misgivings about the accuracy of the Earth

reentry data. All in all, there is much room for error, but that does not make the data useless.

In general it could be said that it is possible to create a TPS system, using real and

available materials that would enable a spacecraft like the SPEAR to compete several aero-

gravity-assists. For any real progress to be made, a much more in-depth analysis of the

materials, trajectories, and heating files must be accomplished. However, assuming that the data

presented here reasonable, TPS is not the limiting factor for the SPEAR’s mission.

66

References

[3.1] A User’s Manual for the Sandia One-Dimentional Direct and Inverse Thermal (SODDIT)

code, Provided by Professor Steven Schneider of Purdue University

[3.2] Updated SODDIT User’s Manual August 1994, Provided by Professor Steven Schneider

[3.3] Williams, S.D., Currey, Donald M., “Thermal Protection Materials, Thermophysical

Property Data,” NASA Reference Publication 1289, 1992

[3.4] Boyce, William E., and Richard C. DiPrima. Elementary Differential Equations and

Boundary Value Problems 7 th Edition . New York: John Wiley & Sons, Inc. 2001, pages 584-

589

[3.5] Haines, Charles W., Student Solutions Manual to accompany Lelmentayr Differential

Equations, 7e and Elementary Differential Equations and Boundary Values Problems, 7e. New

York: John Wiley & Sons, Inc. 2001, pages 223-224

[3.6] http://roger.ecn.purdue.edu/~aae450s/tps/insulation-under-ablators2.txt

[3.7] http://roger.ecn.purdue.edu/~aae450s/fall03/finalrpts/MAGAT/TPS/Materials/

71

4 Structures – Lloyd Droppers

4.1 Introduction

This report covers the basic structure analysis methods and structural design result for the

SPEAR vehicle. The basic structural concept is laid out for the general dimensions, material,

construction type and mounting method. Load estimation and the structural effects of the load

are then evaluated using a finite element analysis program. The report then covers the methods

used in the iterations of the vehicle to minimized structural weight based on the specific load

cases and vehicle geometries. A Matlab code which estimates structural weight based upon a

variance from initial design geometry is then discussed. The various iterations in the design are

briefly discussed as far as their effect on structural weight. A Final Vehicle is then discussed as

far as the structure is concerned.

The structural analysis for this report and this project should be seen as an attempt to

approximate the structural mass of the entry vehicle. For this estimation it is not necessary to

have an in depth model for each individual component and mounting structure, rather a rough

shell model should provide the necessary fidelity for the purpose of weight evaluation. The

analysis method was kept simple in part to improve the turn around time on the design iteration.

Furthermore the design is not optimized structurally in any sort of methodical fashion, rather

attempts are made to adequately reduce the weight of the structure such that the weight estimates

are reasonable considering future weight reduction by structural refinement, and weight addition

to account for the unaccounted for loads in this analysis. With these prevision taken into account

the structural analysis of the entry wedge is presented below.

72

4.2 Requirements:

The general requirements of the structures portion of the vehicle are to design the

structure and estimate the structural weight. To do this the methods handout lays out a

requirement to analyze the vehicle loads and use a simplified finite-element method to compute

structural weight. From the MSFC-HBDK-505 the buckling load required a factor of safety of

1.4, and the composite stress factor of safety was also 1.4 unless in a discontinuity area in which

case the factor of safety is required to be 2.0 or greater. (Ref 4-6)

4.3 Vehicle Concept:

The basic concept for the structure is based upon the geometries required for

aerodynamic and aeroheating performance, as well as the necessary internal volume required by

systems. The structure is a panel mounted monocoque honeycomb structure. The general design

is a flat sided wedge with the TPS mounted on the windward half of the wedge. The structure is

designed to be a cold structure with internal temperatures staying below 175 degrees Celsius.

There is a front bulkhead for the mounting of electronics, and a more detailed component layout

can be seen in the systems report.

The general dimensions which are open to iteration due to structural concerns are the tip

radius; the total wedge length and width; and the wedge half angle. These are all parameters

which could be changed due to structural concerns, however in the early design it appeared that

their effect on other aspects of the design were more dramatic than their results on the structure.

Due to this the structural design was concerned with giving a minimal weight vehicle within the

given dimensional constraints, and giving feedback about the structural weight implications of

such changes, in order to attempt to minimize structural and overall weight..

73

The wedge structure is primarily a composite honeycomb, illustrated in Figure 4.1. The

face sheet will be made of a high-modulus graphite epoxy due to buckling rather than strength

being the limiting factor in the vehicle design, as will be shown in the analysis portion of the

report. The face sheet lay-up will be [0,+45,90]s which acts as a quasi-isotropic material

allowing simpler modeling, and the modulus properties are shown in Figure 4.2. (Ref. 4-1) The

honeycomb material is low density HRH 327, a glass reinforce polyimide honeycomb. The

honeycomb material has minimal structural implications at the fidelity of this design and was

chosen for its relatively good structural properties as well as it thermal insulation and probable

coefficient of thermal expansion match with the composite face sheet. (Ref 4-2)

Figure 4.1: Honeycomb sandwich Construction

74

Figure 4.2: Extensional Modulus, [0i/+45j/90k] Family

For the purpose of this analysis the mounting of the components will not be considered,

and the components will be modeled as lump masses at the mounting points. Also neglected in

this design are the fitting and joints on the composites shell. In order to estimate the structural

mass a correction factor needs to be used. Two different methods are laid out in Spacecraft

Mission Analysis and Design (SMAD) and a masters project paper from Georgia Institute of

Technology (GIT). (Ref 4-3, 4-4) The SMAD version is used for spacecraft mostly satellites and

estimates a structural mass percent of 8-12% injected weight and 15-25% dry weight. SMAD

recommends 10% extra mass for fittings and fasteners with a 25% mass allowable for future

growth. The GIT versions is a weight correction based upon correction factor between actual

structural weight and a simplified shell analysis. The GIT paper recommends a weight increase

of 36.7% for propellant tanks and 90% for primary structure. For this analysis the GIT 90%

weight addition will be used and the structural weight percent will be baselined against the

SMAD numbers to verify reasonable numbers.

75

4.4 Load Estimation and Boundary Conditions:

For loads estimation many different loads were initial considered, eventually only static

aerodynamic pressure and launch acceleration loads were taken into account. Shock loads from

parachute deployment; Thermal; and Random Vibration, both launch and aero acoustics loads

were considered but determined to be beyond the scope of this level of design and would need to

be evaluated if this concept is taken further. Various other loads such as orbital correction burns

were considered to be incidental and not analyzed.

The acceleration launch load is based primarily on the launch vehicle and trajectory.

When the proper acceleration value is given for the launch load, the loads are simply the mass of

each of the components at the component location times the acceleration. This was initially

modeled as pressure loads and nodal loads on the structure, Figure 4.3, in order to expedite the

turnaround time on the modeling the loading was changed to a pure gravity load with the

components added as non-structural lumped mass. The surface of the SPEAR was partitioned at

the locations of the components and that partition was given the component weight. The

component was panel mounted and the side of the mounting was iterated until a reasonably

symmetric load case was converged upon in order to minimize the total load. For the initial

76

Figure 4.3: Nodal gravity loads

structural evaluation a 5 g vertical load will be used until more specific values from propulsion

can be used. The boundary conditions used were fixed constraints on the four aft vehicle

corners. This boundary condition simulates a possible arrangement of mounting the vehicle to

the payload fairing.

The aerodynamic static pressure load is based primarily on the aerodynamic drag and lift

value for a specific trajectory run. For the main body the load is analyzed as a pressure load on

the windward surface of SPEAR as given by aerodynamic for the maximum pressure throughout

the trajectories. The body is also put under an acceleration load with magnitude and direction

given by the MDO and trajectory as the worst case acceleration from aerodynamic deceleration.

A fixed boundary condition on the leeward surface is used to constrain the vehicle for the

pressure load, while such a boundary condition is not physically true it is necessary due to the

numerical nature of the FEA and infinite displacements seen if a boundary condition does not

exist. For the aerodynamic deceleration case the windward surface is given a pin constraint

meant to give a reasonable stress values at points not local to the boundary conditions. An

analytical investigation of the compressive stress in a flat plate decelerating under a uniform

pressure is given in the appendix as a boundary condition validation. While these two distinct

loading cases are not precise over the whole vehicle in their estimation of stresses, they should

give reasonable stress value for the whole vehicle under the aerodynamic deceleration loading

when analyzed as a system. The load was evaluated with a worst case full fuel load, and is

found to be a trivial load for buckling, but on the same order of magnitude for stress as the

gravity load for a 3.2 g deceleration given by earth MDO.

77

4.5 Analysis Method:

The analysis was done with ABAQUS, a finite element method commercial software.

Pro/E was used as the modeler and using STEP files the geometries were transferred to

ABAQUS where the model was meshed and analyzed. ABAQUS was initially verified to work

for various loading condition, only a honeycomb beam analyzed for deflection, stress and

primary buckling mode will be shown for brevity. A quick run through of the ABAQUS

procedure will then be overviewed.

Before ABAQUS is used in the analysis of the SPEAR structure it was necessary to run

trial plates and compare the finite element analysis to analytical solution. For the analysis a

simply supported column was used with dimension shown in Figure 4.4. The critical buckling

pressure was determined in ABAQUS as 5771 lbs (Figure 4.5) using a test load of 1 lbs and

analytically evaluated using the following equations as 6072 lbs. This is a 5% difference in the

analytical and FEA which is reasonable for this analysis. The same column was also evaluated

for stress and deflection when a 4000 lb point load was applied on its tip. The stress analytical

was 3.69e5 psi compared to the 3.67e5 psi FEA (Figure 4.6), while the deflection analytical was

210 inches compared to 211 inches in the FEA. The comparisons show validation of the models

through comparison to simplified analytical solutions.

Figure 4.4: Test panel Geometry (ref 4-2)

78

Figure 4.5: Plate Buckling

Figure 4.6:Plate Bending Stress, psi

79

Once the model has been validated the actual vehicle geometries and loading needs to be

analyzed. The structure is modeled as a simplified shell in Pro/E with the vehicle geometries

then exported as a Step file (.stp). The Step file is imported into ABAQUS and the individual

shell components are assembled and material properties are applied as shown in Table 4.1, and

composite shell properties are applied to the vehicle. The individual component locations are

sketched onto the vehicle and a non-structural mass is applied to those specific sections of the

shell. An image of the mass locations can be seen in Figure 4.7. The individual Component x, y,

and z locations are given by systems and numerical values for each equipment cg can be seen for

the last 2 iterations on in the systems section. Discussion with systems gave each component’s

geometry and appropriate reference shape which is applied at the same location on one side of

the structural modal as it is in the systems model. The side for the components is then varied

during the structural analysis and each component side is determined to reduce structural weight.

Once all the masses are correctly positioned the loading and boundary conditions are applied and

the structure is meshed. The model is then solved for the loads and boundary conditions

discussed in the load estimation and boundary condition section of this report. The results are

viewed, primarily the deflections for buckling and von Mises stress for static loads. Of

important note is that the deflections seen in the buckling analysis are not true deflections, rather

they are normalized deflections as the buckling analysis is an eigenvalue analysis which finds the

mathematical critical buckling load.

Table 4.1: Material Properties (reference 4-1,4-2)

Material Density (kg/m3) Elastic Modulus (Pa) Poisson’s Ratio Yield Stress (Pa)

High Modulus Graphite 1520 5.55e10 .29 2.898e8HRH 327 Honeycomb 72.65 4e8 .32 -

80

Figure 4.7: Iteration 0 lumped mass locations

In order to give an understanding of the structural portion of the iterative design an

example of the first vehicle iteration is given. The vehicle geometries have been given in the

systems section; the structural variables of importance for the first iteration are 0.03 m nose

height, 0.8 m length to bulkhead, 2 m length, 1.6 m width, and 10 degree half angle. These are

input into ABAQUS using the previously laid out method with a 0.0065 m honeycomb thickness

and a 0.0008 m composite thickness, the thinnest possible composite for the lay up geometry

used. (ref 4.1) The boundary conditions for g loading is fixed deflections at the bottom corners,

and the load is a 5 g vertical load, Figure 4.3 shows a vector illustration of the loading. For

pressure loading the load used was a nominal 5 g deceleration for a vector normal to the bottom

plate, and an equivalent pressure load on the bottom plate. These nominal values were used in

lieu of actual number from aerodynamics and trajectory, which were not received until later in

the semester. The images from the buckling analysis of acceleration loading and the static

analysis of the launch and pressure loading are shown in Figure 4.8.

81

Figure 4.8: Left to right: pressure stress (MPa), launch stress (MPa), buckling deflection launch

Since the factor for safety is 7.43 for the stress from the g load, and 3.2 for the pressure

load, and 1.50 for the buckling launch load; the launch buckling is the critical factor with the 1.5

versus the 1.4 factor of safety needed according to MSFC-HBDK-505. Since the buckling

factor was too high the honeycomb thickness was decreased until the proper FOS is met. If

stress was the driving factor the thickness of the faceplate could be increased if it was an axial

loading or the honeycomb thickness could be increase if it was a bending load. It is desirable to

only increase the honeycomb thickness due to its much lower density than the composite

faceplate. Since the factor of safety are meet, though slightly exceeded with this design, the

weight of the structure is modified by the factor of 90% discussed earlier and the new

dimensions are given to systems for evaluation in the next iteration.

One further analysis was that of the rear flap, assuming the flap acts in the worst case as a

simple flat plate, rather than an articulated flap. The rear flap can be considered to be a clamped

cantilever beam under pressure loading from aerodynamic considerations, and a opposite

acceleration load from the TPS mass and structural mass. A simple matlab code was written, and

put in the appendix, to solve the for the beam bending equations given below where tf is the face

82

thickness; h is the honeycomb height; w is the plate width; P is the force per unit length; l is the

total length; M is the moment; and f is the stress in the faceplate. The loading was determined

to be worst case if only the pressure load was considered, and a pressure of 5000 Pa was given

by aerodynamics.

(ref 4-2)

For the plate geometries given by systems, specifically a length of .55 m, an FOS of 1.4 was

found for the minimum weight when the tf=.0008 m, and h=.0038.

4.6 Matlab:

In order to evaluated the weight of SPEAR in different configurations a MATLAB code

was written. The code takes the various geometric parameters and estimated structural weight, in

this fashion allowing reasonable weight estimation at the beginning of an iteration. The code

was tested for weight estimation against Pro/E and a 3D model of SPEAR and is within 1% of

the Pro/E weight, the slight difference coming from the corner geometries. In addition to

estimating the weight of a specific geometry the code was also used to create carpet plots of

weight vs. geometry to help visualize structural trends. The weight estimation was based solely

upon the surface area of SPEAR which is reasonable due to the use of the minimum thickness

graphite composite face plate and varying the honeycomb thickness. The code is fed the

thickness of the faceplate and the honeycomb, the density of the faceplate and the honeycomb,

and the vehicle geometry. From these inputs it can calculate a structural weight and can estimate

the weight of a vehicle of different size assuming similar faceplate and honeycomb thickness.

Due to this the weight estimation remains reasonable until the faceplate thickness needs to be

modified due to high stress, because the honeycomb thickness can be modified to improve the

83

structure with minimal weight impacts. Figure 4.9 is a carpet plot for estimated structural mass

given a length and width. The black lines are line or equal area, in other words, how for the

same aerodynamic surface area the structural weight increases dependent on the specific length

and width. These line indicate that structurally it is more efficient to have a vehicle roughly

twice as wide as long. This is very much in conflict with aerodynamic which indicates that a

longer skinnier vehicle is preferred. As can be seen in the rest of the paper aerodynamics is the

bigger driver in this vehicle and the vehicle is long and slender in opposition to what would be

structurally preferred. The code for these calculations as well as a version using length and angle

instead of width can be seen in the appendix.

1 2 3 4 5 6 7 80

50

100

150

200

250

300

350

400

Length (m)

prec

orre

ctio

n st

ruct

ure

mas

s (k

g)

W=1 (m)W=1.75 (m)W=2.5 (m)W=3.25 (m)W=4 (m)IsoArea line

Figure 4.9: Spear length and width vs. Mass

4.7 Alternative Designs:

84

This report covered the method of evaluating a monocoque composite honeycomb

structure for buckling and stress in a static pressure and launch gravity load environment.

Initially various other structures were considered in including a blade stiffened skin structure and

a skin stringer structure. Also considered were other materials such as titanium for the faceplates

and as primary structure; and aluminum as the primary structure, faceplates, or as the

honeycomb. While the evaluation of the materials led to a composite vehicle as the lightweight

option, other constructions types are brought up as backup in case the current structure proves

insufficient. Of interest in the late portions of the analysis is the possibility that aluminum or

titanium availability in thicknesses thinner than the composites used might be able to yield

lighter overall vehicle weight. Future work on similar projects should take minimum thickness

availability of material into consideration when converging on a design. Even with possibility of

lighter solutions with a more in depth design, the vehicle structural weight percentage appears to

be in the ball park of historical spacecraft values, as will be shown later in the structures report.

Iterations

Various iterations were done on the vehicle, and each of these was evaluated for

structural weight. A table of the structural weight, vehicle geometries, and structural weight

percentages for each of these vehicles is given below in Table 4.2. During the iterations three

main factors were found to be of importance, minimizing overall vehicle volume, moving

component mass as far aft as possible, and minimizing component weight. These factors are

mostly intuitive, and the analysis supports the intuitive guesses as to the maximizing of structural

performance. Minimizing vehicle volume leads to less mass due to less volume to support

structural, and thus less structure. Moving components as far aft as possible is helpful because of

the increased buckling load which is due to the effective minimization of plate length that is

85

loaded. Minimizing component weight is useful because of the acceleration loading, less mass

equals less force which leads to lower structural mass.

Table 4.2: Structural Weight per iterationIteration mass

(kg)angle

(degree)length

(m)width (m)

Structural mass (kg)

Structural mass

% injected

Structural mass % dry

0 357 20 2.4 1.6 51.3 0.14 0.16

1 527 5 5.9 1.6 112.1 0.21 0.24

2 536 8 4.2 1.6 73.3 0.14 0.15

3 285 5 3.5 1.2 37.9 0.13 0.15

4 232 5 3.3 1.2 36.0 0.16 0.17

5 286 4 4.0 1.2 44.0 0.15 0.17

6 399 4 4.1 1.3 45.4 0.11 0.13

7 365 4 4.1 1.3 44.3 0.12 0.14

For the above table the length and width giver are for that of the whole vehicle rather

than the structure particularly. As can be seen on the table the structural mass percentages were

slightly high versus the historical percent injected (.8-.12) and slightly low vs. the historical

percent dry (.15-.25). One iteration of note is iteration 5, which was not given a full structural

analysis due to a rapid change to iteration 6. Therefore the weights for iteration 5 are to be

viewed as suspect and included solely for completeness of data. The worst case for structural

efficiency occurs for very large relatively empty spacecraft. In the case that a large space craft is

to be used it may be necessary to some sort internal framework or modifying thickness across the

vehicle. As the final iteration is a relatively small vehicle these measures were not necessary.

86

4.8 Final Vehicle:

The final vehicle iteration that was run was iteration 7. The vehicle structural variables

of concern are length of 3.025 m, width of 1.2 m, front height of .03 m, and a bulkhead offset of

1.6m. From the systems cg analysis the vehicle components were all panel mounted in their

appropriate cg positions, as can be seen in Figure 4.10. The minimum stress and buckling

occurred with all the vehicle components mounted on the top with the exception of the two

parachutes, and the TPS mounted on the bottom, the UHTC nose mounted on the front, and the

gyros mounted on the central bulkhead. During the stress analysis the graphite epoxy faceplate

thickness was able to be the minimum manufacturability thickness of .8 mm, and the honeycomb

thickness was found to be 1.3 mm thick. The honeycomb thickness would probably be increased

due to stiffness requirements for vibration stiffness requirements; however this is beyond the

scope of this design.

Figure 4.10: Iteration 7 partitioned skin

87

The vehicle was analyzed for the full set of conditions given in the analysis method

portion of this text. The worst case load was the buckling load with a factor of safety of 1.407,

which was found from the eigenvalue returned by the eigenanalysis, Figure 4.12, at the 5 g

launch acceleration load. The stress from that load was found to be 6.4e7 Pa, Figure 4.13, which

is a factor of safety of 4.53. Since the stress is on a discontinuity the FOS is compared to the

minimum FOS allowable of 2. The stress for the aerodynamic deceleration of 3.2 g at 48

degrees is shown in Figure 4.11 as 7.8e7 Pa for a factor of safety of 3.72, which is to be

compared to the minimum factor of safety allowable of 1.4 from MSFC-HBDK-505. From these

values it can be seen that buckling is the driving factor in this vehicle by a factor of roughly 2.

While localized stresses at component interfaces will have to be investigated in a more detailed

design, the current vehicle is solely buckling dominated.

Figure 4.11: Aerodynamic deceleration load, Pa

88

Figure 4.12: Launch Acceleration buckling

Figure 4.13: Launch acceleration stress, Pa

89

The total structural mass was found to be 44.3 kg for the final iteration. This is a dry

structural mass percent of 12%, and an dry structural mass percent of 14%. These values are

within a reasonable range given previous spacecraft percentage from SSAM.

4.9 Structure Conclusion:

The method of structural analysis on the SPEAR vehicle has been discussed. The various

loading cases were determined and launch and aerodynamic pressure are the two loads used as

the baseline to analyze the vehicle. A honeycomb composite structure has been chosen as the

primary structure and the secondary structure will be taken into account using empirical factors.

The ABAQUS FEA has been validated for both buckling and static loads and multiple iterations

have been run. Currently the vehicle structural analysis methods are sufficiently progressed to

have iterations with reasonable structural weight and geometry estimations of the structure. A

vehicle structural mass of 46.3 kg was estimated with 13% structural mass for a 1.3 m wide, 4 m

long vehicle. These values were then fed to systems for integration with the vehicle for a final

vehicle run.

90

Reference

[4-1] “Carpet Plots – High Modulus Graphite/Epoxy”, H. Kim; AAE 352 Handout

[4-2] “The basics on bonded sandwich construction”, HEXCEL, TSB124

[4-3] Space Missions Analysis and Design, James R. Wertz and Wiley J. Larson; 1999

[4-4] “Analytical Structural Weight Estimation of Conceptual Launch Vehicle Fuselage

Components with the Georgia Tech Structural Tool for Rapid Estimation of Shell Sizes (GT-

STRESS)”,Virgil L. Hutchinson, Jr; 2004

http://pweb.ae.gatech.edu/labs/ssdl/Papers/Masters/Hutchinson_8900_GT- STRESS.pdf

[4-5] Spacecraft Structures and Mechanisms from Concept to Launch, T. Sarafin; 1995

[4-6] MSFC-HDBK-505 (Rev. A), “Structural Strength Program Requirements.” Jan. 1981

91

http://pweb.ae.gatech.edu/labs/ssdl/Papers/Masters/Hutchinson_8900_GT-STRESS.pdf

http://pweb.ae.gatech.edu/labs/ssdl/Papers/Masters/Hutchinson_8900_GT-STRESS.pdf

5 Propulsion – Tom Jennings

92

6. Mars Trajectory – Mike Grant

6.1 Introduction

Gravitational assists have been widely used in interplanetary missions. When a

spacecraft travels near a planet, moon, or other body, the gravitational force influences the

interplanetary trajectory of the spacecraft. The magnitude by which the planet influences the

interplanetary trajectory is governed by the mass of the planet, the lowest altitude that can be

flown during the planetary pass, and the approach conditions to the planet. Consequently, these

assists have the capability of changing the shape and orientation of heliocentric orbits, thus

providing an increased capability for interplanetary trajectory design.

A planetary pass influences the interplanetary trajectory by providing a change in

direction of the trajectory and a change in energy of the heliocentric orbit. However, the turning

of the spacecraft provided by the planet is constrained when using gravity alone. In order to

provide an increase in turning capability around the planet, the vehicle may be permitted to fly

though the atmosphere of the planet. The aerodynamic lift, when directed towards the planet,

would augment the turning force around the planet. The utilization of gravity and aerodynamic

forces is appropriately referred to as an aero-gravity-assist and is studied in this report.

6.2 Background

Dr. Longuski, along with several graduate students at Purdue University, is investigating

the feasibility of performing an aero-gravity-assist around Mars and Venus to improve

interplanetary trajectory design. In order to effectively design the interplanetary trajectory,

simplifying assumptions were used by Tracy Smith, graduate student at Purdue University, for

93

the atmospheric flight of both planets. The details of Tracy’s analysis may be found in the

preliminary report, Ref. 6-1. The focus of the senior design class was to design a vehicle and

perform a more detailed, although preliminary, analysis of the atmospheric flight. This section

focuses on the Mars trajectory only and the design of the trajectory.

Only the nominal mission is considered in this report. Hence, the dispersed effects of the

Martian atmosphere and potential error in the delivery state to the planet are neglected. Thus, the

controller is not required to fly out any dispersed scenarios from the nominal. Since only the

nominal mission was considered, an open-loop, time scheduled controller was sufficient to guide

the vehicle through the atmosphere of the planet.

6.3 Fortran Simulation Overview

The trajectory simulation subroutines for a blunt flat plate were obtained from the AAE

450 course website (Ref 6-2). The subroutines had been modified to simulate the designed

wedge-like vehicle. The trajectory code and corresponding subroutines numerically integrates

the equations of motion (for a rotating spherical planet) from Vinh (Ref 6-3). Various

subroutines were used to calculate flight parameters including aerodynamic forces, trim stability,

and aeroheating. Modifications were made to convert the code to a hyperbolic trajectory near

Mars. The atmospheric file was modified to include the density, temperature, and specific heat

of the Martian atmosphere. The data for Mars was obtained from marsatmo.f (Ref 6-2). The

trajectory code converts the inertial inputs into a rotating spherical coordinate system before the

trajectory is numerically propagated. This conversion is performed as discussed in the Methods

handout (Ref 6-4).

94

The initial and desired exit state (provided by Tracy Smith of Purdue University) of the

vehicle was known and the time in which the vehicle enters the atmosphere was also known (by

propagating the vehicle from the initial state to atmospheric entry defined at 100 km). This time

was then used to determine when the controller should be activated in order to prevent the

vehicle from performing unnecessary attitude adjustments in space. However, the time in which

the vehicle exits the atmosphere is not known since it is coupled with the trajectory. Hence, the

time in which to turn off the open-loop controller must be sufficiently high such that the vehicle

is out of the atmosphere. For this analysis, the trajectory was assumed to be entirely contained in

the equatorial plane. Thus, the initial heading, latitude, and longitude were all set to zero.

6.4 The Trade Space

The trade space is defined as the set of independent variables that may be arbitrarily

modified in search of an optimal solution. The goal of the trajectory design was to provide a

controller (in combination with the proper initial flight path angle) that accurately guided the

vehicle to the desired exit state. The trajectory of the vehicle can only be governed by the initial

flight path angle, bank angle, angle of attack, and propulsive maneuvers. All of these parameters

may be varied in order to obtain an optimal controller. Propulsive maneuvers during the

atmospheric flight are not desired and are only to be used as a last resort. In order to efficiently

perform the turn, the bank angle was constrained to 180o to force the lift vector to be directed

towards the planet at all times. Originally, the bank angle was allowed to vary between 0 o and

180o but quickly proved to be inefficient when attempting to complete the turn around the planet.

Hence, the trade space may be reduced to only contain the initial flight path angle and angle of

attack profile. The amount of propellant necessary to change the initial flight path angle (less

95

than 0.5o) was assumed to be accounted for in the ΔV margin allocated by propulsion for

atmospheric flight.

A desirable angle of attack profile would be a continuous function with respect to time.

Any continuous function consists of an infinite number of points. However, the angle of attack

profile must be defined by a reasonable, finite amount of points. The angle of attack profile is

defined by fifteen points that are equally time-spaced throughout the time in which controller is

active. The angle of attack profile is then generated by performing a cubic spline interpolation

using these points. Thus, the profile may then be modified by adjusting the values of the fifteen

points. The cubic spline interpolation was preformed using Fortran subroutines obtained from

Dr. Schneider at Purdue University. An algorithm that would efficiently search the trade space

described above must be implemented. A random or parametric analysis of the trade space

would be computationally expensive and very time consuming. Hence, an artificial intelligence

routine was implemented to perform an efficient global search of the trade space.

6.5 The Genetic Algorithm – An Overview

In many applications, a globally optimal solution is desired. In most applications,

including aerospace engineering, the identification of a globally optimal solution is not trivial.

The genetic algorithm (GA) provides an efficient means to globally search the trade space for an

optimal solution. As the name of the artificial intelligence method implies, the genetic algorithm

utilizes evolutionary theory during its search for the optimal solution. The genetic algorithm is

initialized randomly throughout the trade space. Each set of solutions, denoted as a generation,

are then allowed to reproduce and create offspring that will form the next generation. The

mating and evolution is biased towards the more fit individuals of a population. Thus, the traits,

96

or values of the trade space, of individuals with high fitnesses will have a greater chance of being

fused into the subsequent generation. The goal of the genetic algorithm is to terminate with an

individual with a high fitness that corresponds to the optimal solution. Figure 6.1 depicts the

flowchart associated with the GA. The genetic operations are explained in the following section.

For a well-developed introduction to genetic algorithms, refer to Ref 6-5.

Figure 6.1

6.6 Genetic Operations

6.6.1 Crossover

After the fitness of each individual in a generation is evaluated, the parents are selected.

This selection is performed randomly but with an increased chance of selection for fit

individuals. Elitism is a function of the selection process in which the fittest individual is

immediately inserted into the subsequent generation. Elitism was activated for each GA run

used in this report. After the selection of parents, several genetic operations are performed when

producing offspring. First, crossover is performed when the genes of two parents combine to

97

Initialize Population

Evaluate Fitness

Parent Selection

Create Next Generation: Crossover

Mutate Offspring

Convergence Criteria Met?

Increment Iteration Number

No

Yes

Record Fittest Solution

form offspring (see Figure 6.2). The probability of crossover is dictated by the crossover

probability input by the user (80% for this study) and the crossover point is randomly selected

during each mating process. The goal of the genetic algorithm is to merge traits of fit parents to

produce offspring that is more fit than either parent. This will increase the speed of convergence

to the optimal solution.

Figure 6.2

6.6.2 Mutation

After the children have been produced from crossover, mutation is performed on the

genes of the children. The probability that a gene will be randomly mutated (within the

constraints of the trade space input to the GA by the user) is dictated by the mutation probability

input by the user. A mutation probability of 5% - 10% was used in this report. Refer to Figure

6.3 for a representation of mutation in which the last gene, or parameter of the trade space, is

mutated. Mutation improves the global searching capability of the genetic algorithm by testing

new solutions in the trade space. If mutation is eliminated from the process or the mutation

probability is set too low, then the genetic algorithm will have a tendency to evolve to local

optimal solutions. If the mutation probability is set too high, for example 100%, then the genetic

algorithm turns into a random searching tool. This hinders the genetic algorithm to perform an

intelligent global search of the trade space.

98

+ =Parent 1 Parent 2 Offspring

Crossover Point

Figure 6.3

6.7 Advantages of the Genetic Algorithm

The genetic algorithm provides many advantages over traditional methods of

optimization. The genetic algorithm provides a relatively efficient method to search the global

trade space. Traditional methods, such as the gradient method, require much computational

power. The gradient method requires evaluation of the fitness of each solution that is in the

vicinity of the test solution, requiring many additional simulations to be performed. However,

the genetic algorithm does not require such additional evaluations. Due to the fact that the GA

does not require nearby information of solutions, the GA performs exceptionally well in a

discontinuous environment that is clearly present when performing trajectory simulations. Also,

the gradient method requires an initial guess that is sufficiently close to the optimal solution

since it is only capable of identifying local extrema. However, the GA, a global searching

routine, does not require a good initial guess. This is advantageous when the dimension of the

trade space becomes quite large. Instead, the GA thrives on the diversity of the random initial

guess, requiring no insight to the location of the optimal solution.

6.8 Application of the Genetic Algorithm to Martian Atmospheric Flight

The genetic algorithm was integrated with the Mars trajectory simulations. The genetic

algorithm performed an efficient global search of the initial flight path angle and angle of attack

trade space when attempting to minimize the error at the exit state. The resulting combination of

99

Mutation

initial flight path angle and angle of attack profile will, in theory, guide the vehicle to the proper

exit state. A solution was identified by a given initial flight path angle and angle of attack

profile. The fitness, or optimality, of this solution was determined by comparing the desired exit

state with the resulting actual exit state. A small exit state error was desirable and corresponded

to a higher fitness value. This fitness was then used during the fitness-biased parent selection

process of the GA.

The Mars trajectory simulations were written in Fortran, whereas the genetic algorithm

was written in MatLab. The GA communicated to the trajectory simulation via formatted text

files that were read by the trajectory simulation. This allowed the GA to modify and influence

vehicle parameters, trajectory parameters, and control parameters during the optimization

process. The input text files are discussed below.

The file trajectory_parameters.txt contains many of the parameters associated with the

trajectory including the:

1.) Radius of Mars2.) Gravitational constant of Mars3.) Mars’ angular velocity of rotation4.) Acceleration at Mars’ surface5.) Initial entry radius6.) Desired exit radius7.) Initial inertial velocity8.) Desired inertial velocity9.) Initial flight path angle10.) Desired flight path angle

The file vehicle_parameters.txt contains many of the parameters associated with the

vehicle specifications including the:

1.) Length of the vehicle2.) Flap length3.) Width of the vehicle4.) Nose radius

100

5.) Axial c.g. location6.) Vertical c.g. location7.) Mass of the vehicle8.) Isp of the engines

The file control_args.inc contains the parameters associated with the controller used to

guide the vehicle throughout the trajectory including the:

1.) Number of angle of attack points used to describe the angle of attack profile2.) Number of bank angle points used to describe the bank angle profile3.) Set of angle of attack points used to describe the angle of attack profile4.) Set of bank angle points used to describe the bank angle profile

In order to determine the fitness associated with a given set of parameters located in the

three files mentioned above, the trajectory simulation communicated back to the GA via the

output text files. The GA utilized the output.out file to determine the fitness of the test solution.

6.9 Fitness Evaluation

The optimality, or fitness, of each solution was determined by comparing the actual exit

state of a simulation to the desired exit state. The parameters evaluated at the exit state include

the flight path angle (γ), radius from the center of Mars, Mars inertial velocity, and turn angle.

The error in all four of these parameters was computed and the absolute value of each error was

summated. Since the genetic algorithm was searching for the maximum fitness, the error was

multiplied by negative one. Thus, the resulting fitnesses were negative with the optimal

(maximum) fitness, associated with no error at the exit state, residing at zero. In order to ensure

that each fitness parameter was weighted equally in the fitness evaluation, each parameter was

normalized based on the corresponding desired value. The flight path angle, altitude (which can

be converted to a radius value), and inertial velocity were all output from the trajectory

101

simulation into the output.out file. The simulation terminated when the actual radius value was

greater than or equal to the desired radius value. Thus, the error in the radius term of the fitness

was usually small, and the overshoot in radius resulted from the finite (one second) time step

used in the simulation. The radius, flight path angle, and velocity error was immediately

computed in MatLab after loading the output.out file. Obtaining the turn angle error was not

trivial since only the longitude contained in the output.out file can be related to the turn angle.

The relationship between the change in longitude and desired turn angle specified by Tracy’s

hyperbolic incoming and outgoing velocity vectors is addressed in Appendix C.

Certain combinations of vehicle design, bank profile, and angle of attack profile resulted

in an undesirable trajectory. For example, if the vehicle had enough control authority, the initial

flight path angle and angle of attack profile may have resulted in the vehicle crashing into the

planet. When such undesirable results occur, a statement specifying the error was output from

the simulation into the output.out file. This would normally result in an error when the MatLab-

based GA attempted to load the file. Usage of the “catch” statement was utilized for these

scenarios. If MatLab erred when loading the file, then the GA assumed the trajectory was

unfavorable, as specified by some output message to the output.out file. Hence, the GA

immediately assigned a poor fitness value to the individual, resulting in a low probably for

selection during the parent formation process.

6.10 Fortran Trajectory Simulation Efficiency

Due to the complexity of an aero-gravity-assist trajectory, simulations must be performed

for each solution in order to determine the exit state for a given solution. From this, it was

important to optimize the speed of the genetic algorithm process. The genetic algorithm was

102

governed in MatLab. Thus, the evolution of solutions was controlled in MatLab’s easy

programming environment. However, simulations were programmed in Fortran. The thousands

of simulations performed in one genetic algorithm analysis dominated most of the computing

power of the workstation. Thus, the efficiency of the Fortran simulations was increased.

Initially, parameters of the trade space were varied by the genetic algorithm and output to

a series text files that were previously explained. The resulting text files were then inserted into

the Fortran simulation via the “include” command. However, this required the simulation to be

recompiled for every trajectory run. This resulted in an execution speed of approximately one

simulation per second. The recompilation was very time consuming and was immediately

eliminated. Currently, these files are specifically created and formatted in MatLab and read into

the simulation, eliminating the need for recompilation of the simulation. This capability was

expanded to include input decks for the vehicle parameters and Martian constants. Thus, the

trajectory code does not need to be modified when the vehicle or trajectory parameters are

modified. Since the simulation is only compiled once before execution of the genetic algorithm,

the optimizer residing in the compiler was utilized. The Fortran compiler in the Unix

environment has the capability of aggressively optimizing the execution speed of the Fortran

code using the “-O5” option. This resulted in an execution speed of approximately three to four

simulations per second.

6.11 Critical Influences on Trajectory Performance

6.11.1 Shadowing

As the iteration process progressed, it was clear that the integrated L/D performance of

the trajectory must exceed the L/D performance (approximately a constant value of 3.0) assumed

103

by Tracy Smith. The performance of a trajectory may be easily evaluated by determining the

exit state error. However, this error is connected with the L/D performance of the trajectory.

Thus, by increasing the L/D performance throughout the trajectory, the vehicle will have a

greater capability to accomplish the mission. The vehicle will be traveling at hypersonic

velocities throughout the entire atmospheric portion of flight. Hence, a Newtonian

approximation was used to determine the forces on the vehicle. In order to increase the L/D

performance of the vehicle at such high velocities, the vehicle must be oriented such that the

upper surface of the vehicle is shadowed from the flow. This result explicitly limited the

minimum angle of attack to be equal to the included angle of the wedge-like body. The L/D

performance also appeared to be critically influenced by the viscous drag interaction and nose

radius.

6.11.2 Nose Radius

In order to achieve high L/D performance at low angles of attack, the nose radius must be

reduced as much as possible. Many of the iterations were performed with a nose radius of 0.005

m. A maximum L/D of approximately 1.5 was achieved for any iteration with such a large nose

radius. After the dramatic effect of the nose radius on L/D performance became known, the nose

radius was immediately reduced to 0.001 m, the minimum value as specified by the Methods

handout (Ref 6-4). This improved the overall L/D performance of the trajectory. Thus, the

minimum nose radius that could be feasibly implemented into a vehicle should be used. The exit

state error for iteration 3 (in which the large nose radius of 0.005 was used) is displayed in Table

6.1. As can be seen, the poor L/D performance (see Figure 6.4) of the trajectory resulted in

significant error in the exit state. It should be noted that a negative error implies that the exit

104

state value is less than the desired value. The corresponding altitude and angle of attack profile

may be seen in Figure 6.5 and Figure 6.6, respectively.

Table 6.1: Iteration 3 Results – Large Nose Radius

Fitness Parameter Error Desired ValueExit velocity error (m/s) -287.299 7344.2

Exit radius error (m) 45.2 3847246Exit flight path angle error (deg) 0.0249 23.940Change in longitude error (deg) -24.886 106.2969

100 150 200 250 300 350 400 450 500-1

-0.5

0

0.5

1

1.5

2

Time [sec]

L/D

[non

dim

ensi

onal

]

L/D vs. Time

Figure 6.4

105

100 150 200 250 300 350 400 450 50030

40

50

60

70

80

90

100

Time [sec]

Alti

tude

[km

]

Altitude vs. Time

Figure 6.5

100 150 200 250 300 350 400 450 5004

5

6

7

8

9

10

11

12

13

Time [sec]

Ang

le o

f Atta

ck (

) [de

g]

Angle of Attack vs. Time

Figure 6.6

106

None of the iterations that were tested throughout the semester performed with an

acceptable L/D. Thus, certain iterations were modified until acceptable performance (L/D of

about 3) was found. These modifications have led to a greater understanding of how to improve

the L/D performance.

6.11.3 Viscous Drag Interaction and Final Iteration Results

Also, the viscous drag interaction is clearly present in the high Mach, low atmospheric

density trajectories at Mars. The viscous drag interaction appears to be detrimental to the L/D

performance of the vehicle. Thus, an effort must be made to minimize the impact of viscous

drag interaction which was neglected in the study performed by Tracy Smith. The effect of

viscous drag interaction is discussed in the aerodynamics section of this report. The viscous drag

interaction may be reduced by increasing the Reynolds number.

A reduction in altitude would result in an increase in freestream density and

consequently, Reynolds number. This method was the main driver for the iterations performing

throughout the semester. In order to fly at lower altitudes, the vehicle was shortened and packed

more tightly in an effort to increase the effective ballistic coefficient. This increase in effective

ballistic coefficient allowed the vehicle to fly at lower altitudes without losing too much velocity

when attempting to complete the turn.

The last iteration performed by the entire team corresponded to the best trajectory

performance of any full iteration. As can be seen from Figure 6.7, the L/D performance was

quite poor. Reasonable L/D performance that approached the L/D of 3 assumed by Tracy Smith

is only achieved towards the end of the trajectory. Note that the L/D profile contains many

107

oscillations. These oscillations are directly connect to the angle of attack profile (refer to Figure

6.8). Due to the compact nature of the vehicle for this iteration, the angle of attack must be quite

high in order to arrest the gain in altitude resulting from traveling at hyperbolic velocities. The

rather large oscillations in angle of attack profile were a direct result of simulating a real

atmospheric trajectory. The angle of attack at the end of the trajectory is quite low, resulting in

an improved L/D performance for this portion of the trajectory. The improved L/D performance

at the end of the trajectory is also related to the altitude profile. As can be seen in Figure 6.9, the

altitude towards the final portion of the trajectory is lowest. This resulted in reduced viscous

interaction drag and, consequently, improved L/D performance. If such a low altitude was

maintained throughout the entire trajectory, the vehicle would have lost too much velocity.

100 200 300 400 500 600 700-1

-0.5

0

0.5

1

1.5

2

2.5

3

3.5

Time [sec]

L/D

[non

dim

ensi

onal

]

L/D vs. Time

Figure 6.7

108

100 200 300 400 500 600 7004

6

8

10

12

14

16

18

20

Time [sec]

Ang

le o

f Atta

ck (

) [de

g]


Figure 6.8

100 200 300 400 500 600 70030

40

50

60

70

80

90

100

Time [sec]

Alti

tude

[km

]

Altitude vs. Time

Figure 6.9

109

Since the L/D performance did not meet that of Tracy Smith’s assumption, significant

error was expected to exist at the exit state. The error may be seen in Table 6.2. Due to the poor

performance of even the best iteration performed by the group as a whole, alternative means in

which to minimize the impact of viscous drag interaction that clearly dominated the L/D

performance were independently explored. The results from this independent study were

obtained at the end of the semester. Thus, no full iteration incorporating the results discussed in

the subsequent section could be performed by the team.

Table 6.2: Final Iteration Exit State Error

Fitness Parameter Error Desired ValueExit velocity error (m/s) -903.361 7344.2

Exit radius error (m) 2125 3847246Exit flight path angle error (deg) -0.3881 23.940Change in longitude error (deg) -1.259 106.2969

6.11.4 Minimizing the Effects of Viscous Drag Interaction

In order to further augment the ballistic coefficient, the mass of the vehicle was increased

from the original iteration 5 value of 285 kg to 1316 kg (comparable to Tracy Smith’s vehicle

mass). Figure 6.10 displays the L/D performance of the trajectory for iteration 6 with the

modified mass. The significant depression in L/D performance in the middle of the trajectory is

clearly caused by the large angle of attack (Figure 6.11) necessary to arrest the altitude increase

in the middle portion of the trajectory (Figure 6.12). Note that the angle of attack was not

allowed to be less than the included-angle of the vehicle in order to permit shadowing of the top

surface. The results of Iteration 5 with the modified mass are shown in Table 6.3. As can be

seen, the vehicle mainly completed the turn (small change in longitude error) but experienced a

deficit in exit velocity.

110

Table 6.3: Iteration 5 Results – Modified Mass (1316 kg)

Fitness Parameter Error Desired ValueExit velocity error (m/s) -355.913 7344.2Exit radius error (m) 507 3847246Exit flight path angle error (deg) 0.0839 23.940Change in longitude error (deg) -2.648 106.2969

100 200 300 400 500 600 700-1

-0.5

0

0.5

1

1.5

2

2.5

3

3.5

4

Time [sec]

L/D

[non

dim

ensi

onal

]

L/D vs. Time

Figure 6.10

111

100 200 300 400 500 600 7004

6

8

10

12

14

16

18

20

22

Time [sec]

Ang

le o

f Atta

ck (

) [de

g]


Figure 6.11

100 200 300 400 500 600 70010

20

30

40

50

60

70

80

90

100

Time [sec]

Alti

tude

[km

]

Altitude vs. Time

Figure 6.12

112

Alternatively, the vehicle length may be increased in order to increase the Reynolds

number. With a much longer length, the viscous drag interaction will be reduced, and the

vehicle will have improved L/D performance at high altitudes. This was clearly observed in the

following case in which the vehicle length was modified from a value of 3.524 m (iteration 6) to

a value of 10 m. As can be seen from Figure 6.13, the L/D performance of the trajectory is quite

higher than other iterations. At a time after the 300 second mark, there is a well defined

reduction in L/D for a short period of time. The reason for this reduction is quite clear when

relating the L/D performance to the angle of attack and altitude profiles shown in Figure 6.14

and Figure 6.15.

It is clear that the significant increase in angle of attack resulted in the reduction in L/D.

As depicted in Figure 6.15, the small angle of attack is not sufficient to arrest the altitude

increase resulting from traveling at such high velocities. Thus, the vehicle commanded a higher

angle of attack in order to return to the apparent desired altitude near 30 km. Hence, the

trajectory could be improved by minimizing these inefficient trajectory oscillations. The results

corresponding to the vehicle resembling iteration 6 with the changed length to 10 m can be seen

in Table 6.4. Note that the turn around Mars was completed (denoted by the small change in

longitude error) with a small velocity deficit at the exit state.

Table 6.4: Iteration 6 - Modified Length (10 m)

Fitness Parameter Error Desired ValueExit velocity error (m/s) -164.772 7344.2Exit radius error (m) 51.5 3847246Exit flight path angle error (deg) 0.0629 23.940Change in longitude error (deg) 0.04 106.2969

113

100 200 300 400 500 600 700-1

-0.5

0

0.5

1

1.5

2

2.5

3

3.5

4

Time [sec]

L/D

[non

dim

ensi

onal

]

L/D vs. Time

Figure 6.13

100 200 300 400 500 600 7005

6

7

8

9

10

11

12

13

14

15

Time [sec]

Ang

le o

f Atta

ck (

) [de

g]


Figure 6.14

114

100 200 300 400 500 600 70020

30

40

50

60

70

80

90

100

Time [sec]

Alti

tude

[km

]

Altitude vs. Time

Figure 6.15

Note that the lowest altitude for this trajectory is well above the highest point on Mars

(Olympus Mons is approximately 21 km above the mean surface of Mars).

The dynamics of this best solution was further analyzed. As can be seen from Figure

5.16, the vehicle was able to complete the change in longitude as desired from the aero-gravity-

assist. In order to ensure the vehicle did not experience any dramatic acceleration, the g-loading

of the vehicle (normalized to Earth’s surface acceleration of 9.81 m/s2) is displayed in Figure

6.17. The acceleration was computed by determining the velocity change experienced for each

time step (from the output.out file). It is clear that the vehicle does not experience significant

accelerations throughout the trajectory of Mars. Note that the negative g-loading values

correspond to a deceleration of the vehicle.

115

0 100 200 300 400 500 600 700 800 9000

20

40

60

80

100

120

Time [sec]

Long

itude

() [

deg]

Longitude vs. Time

Figure 6.16

0 100 200 300 400 500 600 700 800 900-1.2

-1

-0.8

-0.6

-0.4

-0.2

0

0.2

Time [sec]

Acc

eler

atio

n (g

's) [

nond

imen

sion

al]

Acceleration vs. Time

Figure 6.17

116

The efficiency of the physical trajectory is largely associated with the oscillations

experienced throughout the planetary pass. Thus, the capability of the vehicle to arrest the flight

path angle to low values throughout the trajectory is essential. Due to the low density of Mars,

the vehicle must have a great enough control authority to minimize the oscillatory trajectory. As

can be seen from Figure 6.18, the vehicle was capable of maintaining a low flight path angle

throughout the trajectory that remained fairly constant. Figure 6.19 depicts the inertial velocity

of the vehicle throughout the trajectory. Initially, the velocity is increasing and is expected since

the initial point resides outside of the atmosphere of Mars on a descending portion of the

hyperbolic trajectory. The velocity then decays throughout the atmospheric flight and

throughout the ascending portion of the new hyperbolic trajectory achieved from the aero-

gravity-assist.

0 100 200 300 400 500 600 700 800 900-30

-20

-10

0

10

20

30

Time [sec]

Flig

ht P

ath

Ang

le (

) [de

g]

Flight Path Angle vs. Time

Figure 6.18

117

0 100 200 300 400 500 600 700 800 9007000

7500

8000

8500

9000

9500

Time [sec]

Iner

tial V

eloc

ity [m

/s]

Inertial Velocity vs. Time

Figure 6.19

6.12 Direction for Further Analysis

As shown, the concept of performing an aero-gravity-assist appears to be feasible, if

sufficient L/D is achieved. There is a clear and significant interdependency among vehicle mass,

lifting surface area, vehicle length, and angle of attack profile on trajectory performance. All of

these parameters impact the altitude of the trajectory, viscous drag interaction, and angle of

attack profile. Consequently, these parameters influence the L/D performance of the trajectory.

It would be advantageous to be able to implement all of these parameters into the GA for

optimization. However, a major modification must be made to the GA process in order to make

this full optimization possible. The stable c.g. location is currently performed manually by the

aerodynamicist. If this process could be automated, then the GA would be able to vary the

118

dimensions of the lifting surface (and determine a corresponding stable c.g. location) in order to

determine an optimal effective ballistic coefficient and vehicle length that would minimize the

impact of viscous drag interaction. There is a clear competition of flying lower with a small

vehicle or flying higher with a longer vehicle. The optimal combination has not currently been

found. However, it is clear that both the ballistic coefficient and vehicle length, when explored

in more detail, could provide an L/D performance that is capable of performing the aero-gravity-

assist mission.

6.13 Execution of the GA and Analysis Scripts

The execution of the GA and analysis are performed in two separate environments. The

GA is executed on a Unix-based compute server. In order to execute the GA, the user must

follow a series of steps:

1.) Log into a Unix-based compute server (using PuTTY or other telnet program). Note: PuTTY can be downloaded for free (search Google)2.) Move to the directory containing the GA and trajectory subroutines3.) Ensure the vehicle parameters, initial conditions, and planetary constants are properly set in preprocessing.m4.) Ensure the GA parameters and trade space constraints are properly set in GA5.) Execute the GA by entering: genetic_algorithm

This will initiate the GA process that run from the main routine genetic_algorithm.m.

Any parameters associated with the GA are located in this code. Upon execution of

genetic_algorithm.m, the simulation is compiled along with the corresponding subroutines.

After the simulation is compiled, then genetic_algorithm.m executes preprocessing.m.

Preprocessing.m serves as the single location for all trajectory and vehicle parameters that are

not modified by the GA. The parameters in this file must be changed to match the vehicle that is

to be tested. After preprocessing.m performs the necessary computations from the given data, it

119

creates the necessary text files that are read by the simulation. After these actions, the genetic

algorithm performs its optimization process. Genetic_algorithm.m calls fitness_func.m to

perform the simulations and evaluate the fitnesses. This allows genetic_algorithm.m to be

generic regardless of the application since the project specific tasks are performed in

fitness_func.m. Fitness_func.m controls the simulation execution and records the fitness values

based on the output generated from the simulation. In this function, the control text file

(control_args.inc) is modified in order to run the test solution.

After the genetic algorithm has completed, the optimal solution data is stored in

output_save_ga.out, output_save_ga.aer, output_save_ga.qw, and output_save_ga.tw for

analysis. The file output_save_ga.out contains the numerically integrated trajectory parameters.

The file output_save_ga.aer contains the aerodynamic performance data. The files

output_save_ga.qw and output_save_ga.tw contain the heating characteristics of the trajectory.

Also, the history of the genetic algorithm has been stored in ga_results.mat. Analyze_results.m

imports this data, along with the text files, in order to perform an analysis of the GA routine.

Data is output to the command screen of MatLab and various plots are generated. Due to the

limitations of most telnet programs, plots cannot be viewed from the telnet session. Thus,

analyze_results.m is executed from MatLab in a Windows setting with the working directory

coinciding with the directory in which the GA was executed.

120

Reference

[6-1] Longuski and Smith. “Aerogravity Assist Trajectories for Mars-Venus Sample Return

Missions.” Purdue University.

[6-2] AAE 450 Course Website: “http://roger.ecn.purdue.edu/~aae450s/sps_prgm/”.

[6-3] Vinh, Busemann, and Culp. Hypersonic and Planetary Entry Flight Mechanics. University

of Michigan Press.

[6-4] Methods Handout. "Conversion Between Rotating and Inertial Coordinates

[6-5] Introduction to Genetic Algorithms: “http://cs.felk.cvut.cz/~

121

7 Venus Trajectory – Greg Henning

In order to fly a successful aero-gravity assist mission, not only does one need the proper

vehicle, but one also needs a sophisticated trajectory. This trajectory must satisfy the desired

initial and final conditions while taking reasonable assumptions into account. The maneuvers

required for this trajectory must also be reasonable, so as to not defy the laws of physics. For our

mission, a computer simulation was used in an attempt to satisfy all these requirements. This

section will discuss all the methods and reasoning behind the trajectory we have chosen and the

control method implemented to achieve it. Figure 7.1 is a 2D, visual representation of the

desired AGA trajectory. The blue line indicates the path traveled by the vehicle around Venus.

-8000 -6000 -4000 -2000 0 2000 4000 6000 8000

-6000

-4000

-2000

0

2000

4000

6000

2D Trajectory by Greg Henning

X (km)

Y (k

m)

Vehicle TrajectoryVenusEdge of Atmosphere

Figure 7.1

7.1 Initial and Final Conditions

The driving force behind the trajectory design for the aero-gravity assist mission was

determined by the initial and final conditions provided by Tracey Smith. Professor Longuski and

122

his research group have provided the state conditions for the trajectory at the time that it

approached the planet and when it departed. These conditions are shown below in Table 7.1. R

is the orbit radius from the center of Venus, V is the inertial velocity in the planet-fixed frame,

and γ is the flight path angle.

Table 7.1

Venus Initial and Final conditionsR_initial [km] 6501.8 R_final [km] 6501.3

V_initial [km/s] 11.72935885 V_final [km/s] 11.22699679γ_initial [rad] -0.267802878 γ_final [rad] 0.260726461

V∞- [km/s] -2.5372107523x + 4.6309662682y - 3.1250119833z

V∞+ [km/s] -0.6142233463x + 2.6595382310y + 4.3204364298z

It is important to first check to see if these numbers are valid. The initial and final radii

should be greater than that of Venus’ surface. Venus has a radius of 6051.8 km, so it should be

noted that the vehicle is far above the surface, 450 km to be exact. Also, the atmospheric edge of

Venus occurs at about 400 km, so it should be noted that the vehicle starts in space. The initial

and final velocities should be greater than the escape velocity of Venus, so that the vehicle does

not get trapped in an elliptical orbit. The escape velocity can be calculated using equation , see

Reference [7.1].

123

For Venus, the escape velocity is approximately 10.36 km/s, so it is clear that the vehicle would

continue on a hyperbolic orbit. The flight path angle indicates the direction of the velocity

vector with respect to the local horizon, which is the imaginary plane that is perpendicular to the

position vector of the vehicle that passes through the center of the planet. The flight path angle

initially should be a negative number, which suggests that the vehicle is approaching the planet,

which it is. The final flight path angle should be positive, indicating a departure from the planet,

which it is.

Figure 7.2 to the right is a simple picture of

what the initial and final conditions might look like. The

initial state at the top of the figure has a position (Ri),

velocity (Vi), and flight path angle (γi). All these

parameters are defined for the final state as well. The

change in longitude from the initial to the final state is

shown as Δθ, and is measured with respect to the

planet. For example, on Earth, starting in Indianapolis, IN

(Longitude ≈ 86º W) and flying to Honolulu, HI

(Longitude ≈ 154º W) is a longitude change of about 68º.

For our mission, the Δθ for the Venus AGA turns out to

be about 60º. Venus is very similar in size to Earth, so this gives a pretty good idea of how far

the vehicle is traveling through the atmosphere during the mission.

The V∞- and V∞

+ vectors are described in detail in appendix C. They indicate the velocity

of the vehicle at and infinite distance from the planet in the planet-fixed frame. This infinite

124

Figure 7.2

distance can be thought of as a sufficient distance so that the gravitational pull of the planet has

negligible effect on the vehicle. These two vectors uniquely define the angle at which the

trajectory of the vehicle must be turned as it passes the planet. This is easily computed by

calculating the inner product of the vectors to determine the angle between them. These vectors

also indicate the amount of total energy gained or lost during the flyby mission. In a completely

orbital problem with no aerodynamic forces or engine burns, V∞- and V∞

+ should have the exact

same magnitude, as the gravity of the planet alone cannot change the orbital energy in the planet-

fixed frame (the energy changes in the heliocentric frame). Since the AGA mission flies the

vehicle through the atmosphere and exchanges energy with the air, it is expected that the

departure velocity V∞+ should be less than the approach velocity V∞

-. Indeed, the magnitudes of

V∞- and V∞

+ are 6.1359 km/s and 5.1104 km/s, respectively, which indicate a reduction in energy

as opposed to a gain or no change.

One other aspect of the V∞- and V∞

+ vectors is that they are not in the equatorial plane of

the planet because there is a nonzero coefficient in the z direction. This indicates a component of

velocity toward the poles of the planet. In order to simplify the simulations, this aspect of the

flight will be neglected and it will be assumed that the trajectory of vehicle will remain in the

equatorial plane of the planet. This should not effect the simulation in any way as it has already

been assumed that the planet is a uniform sphere, the atmosphere is uniform at all latitudes, and

we assume a non-rotating planet.

The method that Tracey Smith and her colleagues used to obtain these conditions

included many assumptions that ignored many of the details that we are concerned with in our

design. Reference [7.6] is a complete write-up of their methods. A few of their main

assumptions that differ from our methods are listed here:

125

1. The spacecraft used had parameters based on the Hyper X vehicle. The mass of the

spacecraft was 3000 lbs. (1361 kg) and the lifting area of the spacecraft was assumed to be 60 ft2.

2. The trajectory was propagated based on the assumption that there was no lift during the

entry and exit portions of the atmospheric fly-through. Although drag was still accounted for

during these times. The cruise portion of the atmospheric fly-through began when the flight path

angle, , reached zero. The is constrained to remain at zero during the cruise portion of the

fly-through. The lift is “turned on” for this part of the fly-through.

3. The CL and CD values used are 0.0571 and 0.0156 respectively, which are assumed to

remain relatively constant throughout the flight.

4. No rarefied flow, shock waves or viscous drag are considered in this model and no wind

gusts are accounted for.

Clearly, the first assumption does not apply in our design, as we constantly changed the

values of mass, length, and width during the design process. Ideally, our design would be better

than the assumption of using the Hyper X, which was not designed for this mission. The second

assumption is a description of the trajectory propagated by Tracey. Figure 7.3 below is an

altitude vs. time plot of this trajectory. Section 1 of the flight is the descent portion, where the

lift has been “turned off” and only drag is accounted for. Section 2 is the portion of flight

corresponding to constant zero flight path angle. Section 3 of the flight is the ascent portion,

where the lift has again “turned off” and the vehicle is allowed to exit the atmosphere.

126

Figure 7.3

The assumption that CL and CD are constant values suggests a constant L/D during flight,

which isn’t realistic. This assumption doesn’t apply to our problem since the computer code

constantly updates these values based on the gas properties of the atmosphere, the shape of the

vehicle, and the angle of attack at which the vehicle is flying. An L/D vs. time profile will be

seen later to make this very clear.

The assumption that no rarefied flow, shock waves, or viscous drag was considered is

perhaps the biggest assumption made by Professor Longuski’s students. According to the

aerodynamics and MDO reports, the viscous interaction drag is very important to consider at

high altitude flight. Without it, the achievable L/D range is much higher, and the CL and CD

seem reasonable, but including the viscous drag causes the L/D to be reduced, and the mission

becomes more difficult.

The initial and final conditions given to us were extracted directly from a simulation

using their model and the assumptions listed here, along with all the rest of the information in

Reference [7.6].

127

7.2 Venus Properties

Nearly every facet of the trajectory design depended heavily on the unique properties of

Venus and its atmosphere. Venus properties which were taken into account in the trajectory of

this mission are shown below in Table 7.2; see References [7.2] and [7.3]. As far as the

geometric and mass properties of Venus go, Venus is very comparable in size and mass to the

Earth, so the gravitational parameter, μ, is very similar to that of Earth. Compared to Mars,

Venus’ gravitational parameter is nearly an order of magnitude larger. It is clear from the

gravity alone that the trajectory calculations about Mars and Venus are much different.

Table 7.2

Venus PropertiesRadius [km] 6051.800Gravitational Constant (μ) [N-m^2/kg] 3.2486E+14

Rotational Angular Velocity [rad/s] -2.9932E-07

Edge of Atmosphere [km] 400.000

The atmospheric edge of Venus was chosen to match as closely as possible the analysis done by

Tracey Smith. Initially, we only had data for the atmosphere up to 100 km, but the initial

conditions in the last section did not allow the vehicle to drop below 100 km, so the vehicle was

not controllable. Therefore, using a single data point at 400 km from Reference [7.6] and an

exponential interpolation between 100 and 400 km, the atmosphere was modeled all the way up

to 400 km. The exponential interpolation method is reasonable for the high altitudes. Since the

density is so low at high altitudes, small errors will not greatly affect the overall aerodynamic

forces calculated through a trajectory.

128

Another large difference arises in the atmospheric properties of Venus. Figure 7.4 below shows

the density and temperature of Venus, Mars, and Earth at a range of altitudes, see Reference

[7.4]. It is clear that Venus has a much denser atmosphere than Mars and Earth, thus, the

aerodynamic forces on a vehicle will be much greater at similar altitudes. In order to reduce

heating and drag, the vehicle will probably have to be flown at much higher altitudes in Venus’

atmosphere than in the Martian atmosphere.

Figure 7.4

7.3 Trajectory Design

The equations of motion for the mission were integrated using computational methods

written in FORTRAN. This code accounts for the gravitational force describing the orbital

mechanics specified in Reference [7.1], and aerodynamic forces on the vehicle as it approaches,

passes through, and departs the atmosphere of Venus. The complete code can be found in the

appendixes. In order to get the vehicle from the initial conditions (Point A) to the final

129

conditions (Point B), a controller needed to be designed for the vehicle. For the Venus mission,

the method selection has been an iterative process.

The initial control law was a simply block of if statements applied to maintain the vehicle

at a constant altitude or flight path angle in the atmosphere until a specified turn angle was

reached. It soon became clear that this method was not powerful enough to control such a

sensitive mission, so the next step taken was to implement a feedback control system that could

keep updated at each time step. The control scheme chosen was the PID controller. This method

worked well at what it was designed to do, which was guide the vehicle to a specified cruise

altitude and maintain that altitude until a specified turn angle was reached. The idea of

specifying a cruise altitude and maintaining it was never proven to be the most effective method

though, so it was eventually abandoned as well. It turned out that allowing the vehicle to glide

through the descent portion of the flight with the least amount of drag possible was the best

design. Then, when the flight path angle reached zero, the PID controller was turned on to keep

the flight path angle at zero (constant altitude). After a specified turn angle, the vehicle was

allowed to depart the atmosphere with the least amount of drag possible.

This new method mirrored the method used by Tracey Smith, and was much more

effective than previous methods. However, it appeared that the section of the flight where the

controller was implemented was still causing far too much drag. The controller was

commanding inefficient bank angles and angles of attack, which was causing the drag to

accumulate beyond what we were allowed. The final design of the trajectory simply removed

the PID control during the zero flight path angle section and replaced it with a constant AOA that

could maintain a relatively small flight path angle and reduced the drag to a minimum. Each

130

method is discussed in detail in appendix D. Before each method is discussed though, a

discussion of the vehicle’s controllability is presented.

7.4 Vehicle Control

The method for controlling the trajectory of the vehicle depends on the angle of attack,

the bank angle, and the thrusting capabilities of our rocket. In an attempt to maximize the

efficiency of the mission, the ability to thrust has been largely ignored. It may be considered in

future work for correcting exit condition errors. The angle of attack of the vehicle will be

determined by the L/D ratio of the vehicle. In hypersonic flow theory, L/D is at its maximum for

a blunt flat plate when the angle of attack is near zero. L/D decreases as angle of attack

increases. The wedge shape of the vehicle acts like a blunt flat plate when the upper surface is

shadowed from the airflow. To reduce drag and protect the top side of the vehicle, this is exactly

what will be implemented in the trajectory. The angle of attack is constrained by the included

angle of the wedge. Since the top surface is going to be shadowed, the angle of attack has a

minimum allowed value where the top surface is just barely shadowed. This angle of attack is in

fact the same as the included angle. Figure 7.5 shows how this geometry works out, with angle

of attack = α, wedge included angle = ζ, and the free stream velocity = V∞. Since the maximum

L/D occurs at the minimum possible angle of attack, the vehicle should be flown at that angle of

attack whenever possible. It may be worthwhile to increase the AOA slightly in order to

increase the controllability of the vehicle. The other free parameter in the system is the bank

angle.

131

Figure 7.5

Figure 7.6 below shows how the bank angle corresponds to the direction of the lift vector

on the vehicle. This is a head on view of the vehicle, where the thin rectangle at the top of the

vehicle represents the nose radius. The upper surface of the vehicle is always oriented in the

direction of the lift vector.

If the vehicle needs to be moved to a higher altitude, the lift vector should have a

component in the upward vertical direction. This means that the bank angle should be less than

90 degrees, and maximum upward lift will occur when the bank angle is zero. Similarly, the lift

132

V∞

α

ζ

L

L

L90 deg

180 deg

0 deg

Figure 7.6

vector should have a component in the downward vertical direction when a descent is necessary.

This would correspond to a bank angle greater than 90 degrees, and a maximum downward lift

occurring when the bank angle is 180 degrees. If the bank angle is set to 90 degrees, the velocity

vector is pointing completely in the horizontal direction. This corresponds to no vertical lift on

the vehicle.

7.5 ΔV Analysis and Comparison

In order to analyze the “goodness” of a trajectory, or how closely the desired final

conditions are met, one must compare the simulated final conditions with the desired final

conditions. The simplest way to do that is to simply measure the percent error of each of the four

exit conditions (altitude, longitude, velocity, and flight path angle), and try to minimize that

error. Because of the way the simulation code is set up, the simulation can be stopped at a

specified altitude. Therefore, the correct altitude is always met at the final condition, as it

defines the final time step of the simulation. Also, the methods devised for controlling the

vehicle, which will be discussed shortly, allow the user to meet the turn angle (longitude change)

almost exactly by simply tweaking a few of the parameters in the control logic. Once the turn

angle is met, the only two parameters left to match are the velocity and flight path angle.

In space applications, one of the most important factors in interplanetary travel is the ΔV

required for trajectory corrections. Because of this, the “goodness” factor used in our analysis

was the ΔV required to transfer the vehicle from the simulation final state to the desired final

state. If the conditions were met exactly, ΔV would be zero. If the conditions were not met, ΔV

could be found using the cosine law, described by equation and Figure 7.7 below.

133

Figure 7.7

It turns out that in orbital mechanics, the flight path angle and the velocity are very much

coupled. For a given vehicle trying to fly away from a planet, the higher the velocity it is exiting

at, the more quickly the flight path angle will increase. Conversely, if the vehicle is moving

slower, the gravitational pull of the planet has more affect on the trajectory and pulls the vehicle

closer, causing the flight path angle to decrease. In our mission, increasing the velocity of the

vehicle at the final state will increase the flight path angle, and vice versa. Since this is true, and

it has already been discussed that the altitude and turn angle can be met, the only major issue

involved in meeting the exit condition is trying to match the velocity at exit.

The ΔV concept can also be used to understand how worthwhile the AGA mission is

compared to a simply gravity assist mission. The initial and final conditions each describe

unique hyperbolic trajectories that pass near the planet Venus. Figure 7.8 below is a

representation of the approach and departure hyperbolas. The dotted line is an example of what

the AGA that connects the two hyperbolas might look like.

134

ΔVVf

Vγf

γ Local Horizon

0 10 20 30 40 50 60 7050

100

150

200

250

300

350

400

450

500Altitude vs. Longitude by Greg Henning

Longitude (deg)

Alti

tude

(km

)

ApproachDepartureAGA

Figure 7.8

In order to get from the approach orbit to the departure orbit, a maneuver of some sort

must be performed. Typically, this is done with an impulsive engine burn at the point where the

two trajectories intersect. Assuming no atmospheric forces are present, that is the only option.

Using the cosine law discussed earlier in equation , the ΔV needed to go from the approach

hyperbola to the departure hyperbola was calculated to be approximately 1.537 km/s. Referring

to equations , , and , and Figure 7.9 below, the ΔV vector has a component in the direction of the

local horizon and another component in the direction of the radius vector, directed from the

center of the planet. Since these two unit vector directions are orthogonal, the sine law can be

used to find how much of the ΔV corresponds to the change in velocity directed toward the

planet, and how much corresponds to the change in velocity along the direction of flight. Since

most of the drag is accumulated during the cruise portion of the flight where the flight path angle

is nearly zero, these two components are analogous to the total change in velocity due to lift and

drag. The ΔV in the “lift” and “drag” directions were found to be approximately ΔVL = 1500 m/s

135

and ΔVD = 500 m/s, respectively. This suggests that achieving L/D ≈ 3 is necessary to complete

the mission.

Figure 7.9

7.6 Iteration Process

The trajectory simulation is a vital part of the design iteration process. When the vehicle

is flown through the trajectory, the heat flux and temperature on the body is calculated at a finite

number of points. The basic input/output relationship that the trajectory simulation has with the

rest of the design is as follows. Given a set of vehicle parameters including geometry, mass,

center of mass location, and aerodynamic capabilities, the simulation runs to completion. Using

the output data, the feasibility of the vehicle’s design in completing the desired mission can be

easily seen. Decisions can be made from there to change the geometry or mass properties to

136

Local Horizon

Vi

Vf

γi

ΔV

ΔVD

ΔVL

θ1θ2

γf

R

achieve a more efficient flight. On top of that, new heat flux data can be passed on to the

thermal protection system calculation in order to determine how much more or less protection is

needed. This will affect the mass of the vehicle. Once the new TPS is calculated and a new set

of vehicle parameters is decided upon, another simulation can be run. Each new simulation

requires changes in the controller constants or the AOA profile, depending on how drastic the

changes to the vehicle are.

The final iteration resulted in a vehicle with the parameters outlined below in Table 7.3.

The major parameter that the trajectory dealt with was the vehicle included angle. As discussed

before, the included angle limits the possible angles of attack. To maximize L/D, the AOA

should be pretty small, so the vehicle was made to have an included angle as small as possible

without becoming unreasonable. The weight and surface area of the vehicle was also varied

according to what was needed in terms of ballistic coefficient and controllability of the vehicle.

Table 7.3

Final Vehicle ParametersMass [kg] 365Length [m] 3.575Width [m] 1.25Flap Chord [m] 0.25Extension [m] 0.3Nose Radius [m] 0.001Axial cg Location [m] 2.002Vertical cg Location [m] 0.028Wedge Included Angle [deg] 4

The iteration process for designing the optimal controller and trajectory involved a

tedious method of entering parameters, running the simulation, and checking the results.

Basically, for a given vehicle, the AOA, cruise altitude, and cruise time were varied until the ΔV

was minimized. The same basic thing was done for the original PID controller, except that the

137

controller gains were varied as well. This took a lot longer to optimize than the new and

improved control scheme. It also turned out that the Bank and AOA profiles for the new scheme

were much more achievable, and the ΔV was significantly improved.

7.7 Results and Discussion

With the final vehicle parameters and the final trajectory and controller designs, the

simulation was run to completion with only a minor deficit in the velocity. Figure 7.10 shows

the AOA profile and Figure 7.11 shows the Bank angle profile. The AOA is only required to

perform two maneuvers. It starts at the minimum value of 4 degrees, which is the included angle

of the wedge. It then increases to about 5.22 degrees, which is the AOA for which the vehicle is

captured in the cruise section. It then returns to the minimum as the vehicle exits the

atmosphere. The Bank angle is only required to perform one maneuver. The vehicle begins at a

bank angle of zero, then flips to 180º for the remainder of the flight. Figure 7.12 shows the

altitude vs. time, which looks very much like the trajectory flown by Tracey, shown in Figure

7.3.

0 100 200 300 400 500 6004

4.5

5

5.5AOA vs. Time

Time (s)

AO

A (d

eg)

138

Figure 7.10

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5

3

3.5Bank Angle vs. Time

Time (s)

Ban

k A

ngle

(deg

)

Figure 7.11

0 100 200 300 400 500 6000

50

100

150

200

250

300

350

400

450

500Altitude vs. Time by Greg Henning

Time (s)

Alti

tude

(km

)

Vehicle TrajectoryEdge of AtmosphereVenus Surface

Figure 7.12

Figure 7.13 below shows the velocity over the duration of the mission. The red line is the

velocity desired at exit. It is obvious that there is too much velocity deficit to match the final

139

conditions. Fortunately though, the escape velocity for Venus occurs around 10.6 km/s, which is

still below the exit velocity, so the vehicle will still depart the planet on a hyperbolic orbit.

0 100 200 300 400 500 6001.06

1.08

1.1

1.12

1.14

1.16

1.18

1.2x 10

4 Velocity vs. Time by Greg Henning

Time (s)

Vel

octiy

(m/s

)

Figure 7.13

Figure 7.14 shows the longitude vs. time. Again, the red line indicates the desired final

condition. As discussed before, it is easy to match this final condition with only a small error

which is due more to the limited capability of the FORTRAN code. It is clear that the vehicle

has reached the correct position in space for the final conditions. The only requirement that

remains unmet is the velocity vector.

140

0 100 200 300 400 500 6000

10

20

30

40

50

60

70Longitude vs. Time by Greg Henning

Time (s)

Long

itude

(deg

)

Figure 7.14

The velocity vector is defined by its magnitude and its direction. Figure 7.15 shows the

flight path angle vs. time. The middle section that levels off at zero corresponds to the cruise

section of the flight. Clearly, the control scheme is doing what it was designed to do, which was

to maintain a zero flight path angle for a desired cruise time. There was still a slight discrepancy

between the final flight path angle and the desired value. As discussed before, the flight path

angle depends heavily on the velocity. If the velocity were higher, as is desired, the slope of the

graph in Figure 7.15 after the cruise section would have been greater, and the blue line would be

closer to touching the red line. This small error does factor into the ΔV, but not as much as the

velocity deficit.

141

0 100 200 300 400 500 600-20

-15

-10

-5

0

5

10

15Flight Path Angle vs. Time by Greg Henning

Time (s)

Flig

ht P

ath

Ang

le (d

eg)

Figure 7.15

The corrective ΔV needed at the end of the flight was found to be 453.3585 m/s.

Compared to the ΔV = 1537 m/s needed to change orbits without the AGA, this number shows

that the AGA does show promise. A ΔV of over 450 m/s is still very significant though. The

vehicle was only budgeted 300 m/s for orbit corrections. Adding another 450 m/s for the Venus

flyby and, assuming a similar velocity error, another 400-500 m/s for the Mars flyby would

brings the total ΔV budget to around 1200 m/s. That would require much more fuel, which

translates to a higher vehicle mass, which in turn adds significantly to the mission cost. The

mission is still obviously lacking in ability.

It was discussed earlier that in order to complete the mission, an L/D of around 3 or better

would probably be necessary. According to Figure 7.16, the vehicle reached a maximum L/D

right around 1.94 during the cruise section of flight.

142

0 100 200 300 400 500 600-1

-0.5

0

0.5

1

1.5

2L/D vs. Time by Greg Henning

Time (s)

L/D

Figure 7.16

It would seem that flying at a lower altitude would increase the L/D due to the decrease

in viscous-interaction drag. This is discussed in the Aerodynamics section of the report.

However, there was a limit to how low the vehicle should fly to optimize the efficiency of the

mission. Lift and drag are coupled in the sense that at lower altitudes, the vehicle can generate

more lift, and at the same time experiences more drag. Likewise, higher altitudes result in less

lift and less drag overall. The vehicle needs to produce a certain amount of lift in order to

complete the mission, which corresponds to a maximum altitude at which the vehicle can be

controlled. That altitude will produce a certain amount of drag on the vehicle as well. Once the

vehicle is controllable at a particular altitude, there is no reason to fly any lower, since the extra

lift is unnecessary and will be wasted. The only effect will be a build-up of more drag, which is

not what is desired.

143

To see the effect of the viscous interaction drag, a simulation was run using only

Newtonian theory for calculating CL and CD. The way these are calculated is shown here in

equations and .

0 100 200 300 400 500 6001.12

1.13

1.14

1.15

1.16

1.17

1.18

1.19

1.2x 10

4 Velocity vs. Time by Greg Henning

Time (s)

Vel

octiy

(m/s

)

Figure 7.17

The trajectory doesn’t look any different than before, so Figure 7.12 is sufficient to

describe the altitude vs. time profile for the simulation. Figure 7.17 shows the velocity vs. time

plot for the simulation neglecting viscous-interaction drag. With only the Newtonian drag being

accounted for, the mission has been completed with a surplus of velocity. Also, the flight path

angle vs. time plot shown below in Figure 7.18 clearly shows that the final condition has been

met for the flight path angle as well. Figure 7.19 is the L/D profile for this case. Comparing to

Figure 7.16, it is easy to see that the purely Newtonian case is achieving a much better L/D

throughout the flight.

144

0 100 200 300 400 500 600-20

-15

-10

-5

0

5

10

15Flight Path Angle vs. Time by Greg Henning

Time (s)

Flig

ht P

ath

Ang

le (d

eg)

Figure 7.18

0 100 200 300 400 500 600-1

0

1

2

3

4

5

6L/D vs. Time by Greg Henning

Time (s)

L/D

Figure 7.19

145

To compare the new control scheme to the PID controller, the final vehicle was run

through the simulation with the PID control. Essentially, the plots for altitude, velocity,

longitude, and flight path angle vs. time look nearly identical to the figures presented previously.

The ΔV improvement wasn’t vast, as the PID controlled system achieved ΔV = 471.8499 (in

comparison to ΔV = 435.3585 for the new scheme). Along with the improvements in both the

bank angle profile and the simplicity of the scheme, even a small improvement in ΔV shows that

the new scheme is all-around better for the mission. Figure 7.20 and Figure 7.21 below show the

controller effort and the total bank angle for the PID controlled mission, respectively.

0 100 200 300 400 500 600-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

2.5PID Control Effort

Time (s)

Con

trol E

ffort

(rad)

ProportionalDerivativeIntegralTotal Control

Figure 7.20

146

0 100 200 300 400 500 60090

100

110

120

130

140

150

160

170

180

190Bank Angle vs. Time

Time (s)

Ban

k A

ngle

(deg

)

Figure 7.21

147

7.8 Conclusions and Recommendations

Given more time and resources, a more suitable vehicle could most likely be found using

our iteration process. Some major changes to the vehicle would probably need to be done in

order to get better L/D properties. It really doesn’t seem worthwhile at this point to try and fly

the vehicle at lower altitudes. It seems that the best way to improve the L/D at this point is to

make drastic design changes to the vehicle.

Even at the end of the project, there still wasn’t much insight into what sort of

vehicle parameters would produce optimal performance. With the final control scheme and the

final vehicle iteration, a short trade study was done to see the effect of changing the vehicle

length and weight. Table 7.4 below lists the corrective ΔV required for each vehicle

configuration when flown through the full trajectory. The numbers in red indicate the final

iteration performed by the team. The trade study was done by adding and subtracting 20 kg from

the mass as well as adding and subtracting 0.2 m from the wedge length. It would seem that

increasing the vehicle mass and shortening it produces the most desirable ΔV. Looking at ΔV

alone doesn’t say much unless the mass of the vehicle is considered as well. The amount of

propellant needed depends on the ΔV and the mass of the vehicle. Table 7.5 shows the ΔV

multiplied by the vehicle mass for the same trade study. Clearly, the case that seemed optimal

from Table 7.4 is not the best case when taking mass into account.

Table 7.4

DeltaV needed to correct for differing masses and plate lengths 345 kg 365 kg 385 kg

3.375 m 464.9905 445.0025 432.1744

3.575 m 461.0182 453.3585 437.3555

3.775 m 476.6398 449.0747 443.9124

148

Table 7.5

DeltaV x mass for differing masses and plate lengths 345 kg 365 kg 385 kg

3.375 m 160421.7225 162425.9125 166387.144

3.575 m 159051.279 165475.8525 168381.8675

3.775 m 164440.731 163912.2655 170906.274

The main conclusion that can be drawn at this juncture is that in order to fully

understand the behavior of the AGA mission, one must have an accurate model for the drag on

the vehicle. The amount of velocity lost is a huge factor in determining whether or not the

mission is worthwhile. The final conditions were very different when viscous-interaction drag

was considered as opposed to neglected. The ΔV needed to correct the trajectory was not

unreasonable, and the fact that escape velocity was maintained is promising, but it would be

foolish to do a more detailed design without a greater understanding of the aerodynamic forces

on the vehicle during atmospheric flight.

149

Reference

[7.1] Greenwood, Donald T., Principles of Dyanmics, 2nd edition, Prentice-Hall, 1988, pp. 213-

216

[7.2] Professor K.C. Howell, AAE 532 notes, Fall 2004, Purdue University

[7.3] Seiff, A.; Schofield, J.T.; Kliore, A.J.; Taylor, F.W.; Limaye, S.S.; “Models of the Structure

of the Atmosphere of Venus from the Surface to 100 Kilometers Altitude”, Advances in Space

Research: The Official Journal, Vol. 5, No. 11, 1985

[7.4] Schneider, Steven P, Methods for Analysis of Preliminary Spacecraft Designs, AAE450,

Spacecraft Design, Purdue University, Fall 2005

[7.5] Vinh, N., Busemann, V., and Culp, R., Hypersonic and Planetary Entry Flight Mechanics,

Univ. of Michigan Press, 1980.

[7.6] Smith, T., and Longuski, J., Aerogravity Assist Trajectoris for Mars-Venus Sample Return

Missions, Prepared for Prof. Schneider, AAE 450 Instructor, Fall 2005

150

8 Mars Multidisciplinary Design Optimization – Anthony A.

Sanders

8.1 Introduction:

The purpose of the MDO, per S.P. Schneider AAE450, Fall 2005, Tentative Team

Member Assignments, “is to iterate vehicle designs, control angle of attack and roll angle, and

run code developed by other group members”.

The Mars MDO ran the original traj.f code to get a feel for how it ran, and how changing

the parameters changed the output. After working with the code for several weeks, it became

apparent that an iteration process would be much more efficient. Since changing several

parameters and determining how that affects the vehicle was the main job of the MDO, the Mars

MDO created several MatLab codes to iterate and analyze the data from traj.f, aeroprop.f, and

altvmap.for. Explanations for the codes can be found after the Method section. The Mars MDO

was in charge of helping aerodynamics determine stable trim conditions for any wedge

parameters and to pass that condition to the trajectory persons. The trajectory persons would then

determine if the vehicle could fly the trajectory through each planet.

Along with determining stable trim conditions for the vehicle, the Mars MDO analyzed

the optimization of L/D and the effects of drag on the mission.

The part of the MDO was ambiguous at best. Although the definition of the role of the

MDO included controlling angle of attack and roll angle, those things were truly controlled by

the trajectory persons because they used them in their controller. The part of the MDO was not to

control those parameters, but to vary them and determine their effect on the mission. Did a

151

higher angle of attack produce higher L/D?? Did it increase drag as well?? The relationship

between changing vehicle parameters, the angle of attack, and planet atmosphere was intensely

complex. Although it seemed that the MDO position was well defined, that was not so as the

semester was went on. Many times the Mars MDO merged into the position of trajectory or

aerodynamics and spent a majority of his hours on these subjects. This produced an unbalance

between positions because the part of the MDO was not completely filled due to his need in

other places. Below is the method the Mars MDO took in this project. Note that much of what is

stated is from an aerodynamic point of view; this is because the majority of what made this

mission pass or fail was the aerodynamics of the vehicle.

8.2 Method:

In order to iterate on the vehicle design, optimization points had to be determined. L/D

was a strong factor in the success of the mission because it determined how much turn the

vehicle was able to obtain, as well as how much velocity was lost due to drag in the atmosphere.

For that purpose, maximizing L/D for the mars aero-gravity-assist was picked for the first

optimization point. The initial optimizations were carried out with a blunt flat plate due to the

lack of a working aerodynamics code for a wedge, but because a wedge with the top or bottom

shadowed acts like a flat plate, the results helped give a general trend.

The central code was provided by Professor S.P. Schneider, so the first step was to run

the FORTRAN code, traj.f, to get a general understanding of what how the code ran and how the

vehicle parameters would initially affect the trajectory of the vehicle through the atmosphere.

This code reads in several other FORTRAN functions, including aerodat.f which calculates the

aerodynamic properties of the vehicle. Initially, running traj.f for different vehicle parameters

152

required opening traj.f, manually changing the parameters, compiling, and then actually running

the code. When changing the vehicles length, the xcg location changed as well. Although the xcg

location followed a general trend of approximately one half the total length of the plate from the

front of the plate, a more accurate path for finding the best xcg location to use for each plate

length was in need.

To get a general understanding of the effect of xcg location and stability, the aeroprop.f

code was put to use for the first iteration vehicle parameters. The vehicle parameters used for the

first iteration can be found in Table 22.

Table 1: First Iteration Vehicle Parameters

Vehicle Parameter Meters

Plate Length 2.451

Flap Length 0.25

Width 1.64

Nose Radius 0.005

Ycg Location 0

In order for a vehicle to be stable, the moment coefficient about the xcg location must be

zero, and its slope must be negative. Aeroprop.f also outputs the Cm,cg for each flap angle, β, and

for each xcg location tested. Figure 4: Plot of Cm,cg versus angle of attack shows the Cm,cg for the

maximum L/D case, xcg = 1.29 m. Note that there is a wide range of angles of attack that the

vehicle could be flown at for the range of flap angles chosen. This was good because the vehicle

may need to have to fly at different angles of attack throughout the mission.

153

0 2 4 6 8 10 12 14 16 18 20 22 24

-25

-20

-15

-10

-5

0

5

x 10-3 Plot of Cm,cg versus

(deg)

Cm

,cg

lplate= 2.451lflap= 0.25width= 1.64rnose= 0.005xcg= 1.29ycg= 0

Flap Angle ( ) = -8Flap Angle ( ) = -4Flap Angle ( ) = 0Flap Angle ( ) = 4Flap Angle ( ) = 8

Figure 4: Plot of Cm,cg versus angle of attack

The stable xcg location was then given to the trajectory persons so they could run their

trajectories. After this point, analysis of the wedge vehicle began and the Mars MDO focused on

helping the aerodynamic person develop her method.

Although not shown in this section, the Mars MDO did a full analysis of the aerodynamic

properties alongside the aerodynamics person. This was required due to suspicious vehicle

behavior after the initial wedge aerodynamics code was written. The Mars MDO helped re-

derive all the aerodynamic equations for the wedge and write the code in Fortran, using the

existing aerodat.f code provided by professor Schneider as a template.

One of the major issues for the design of the mission was whether viscous interaction

drag had a significant effect on the aerodynamics. The first step was to analyze the equations.

Equation 1 shows the Lockheed Viscous-Interaction correlation, where VI stands for Viscous-

154

Interaction and was calculated using Equation 2. The correction was then applied to the

CD,Newtonian to produce the CD,actual, see Equation 3.

Equation 1: (Ref 7-1, pg 37 eq. 95 )

Equation 2: (Ref 7-1, pg 38 Figure 13)

Notice that viscous interaction effects, VI, is directly dependent on mach number and

Reynolds number. Although the Mach number may be very large, for very low densities the

Reynolds number is very small. This led to very high VI effects.

Equation 3: (Ref 7-1, pg 39 eq 96)

Figure 5 is a plot of the temperature and density of mars atmosphere versus altitude.

Mars atmospheric density is very low, so the affects of viscous drag will be high.

155

0 2 4 6 8 10 12

x 104

10-7

10-6

10-5

10-4

10-3

10-2

10-1

Altitude (m)

Den

sity

(kg/

m3 )

0 2 4 6 8 10 12

x 104

130

140

150

160

170

180

190

200

210

220

Mars Atmospheric Data

Tem

pera

ture

(K)

Figure 5: Plot of Temperature and Density of Mars Atmosphere versus Altitude

Table 2: Final Wedge Parameters

Wedge Parameters

lplate (bottom surface) (m) 3.575

lext (m) 0.3

lflap (m) 0.25

width (m) 1.25

nose radius (m) 0.001

xcg (m) 2.02

ycg (m) 0

zcg (m) 0.028

Full Wedge Angle, delta, deg 4

156

For the last iteration wedge vehicle design, see Table 2 for details, Figure 7 was the

comparison of drag components. Altvmap was initially run for several angles of attack and a

constant velocity of 7000 meters/sec. Figure 6 shows the L/D of the vehicle for various angles of

attack. Altvmap runs the vehicle through an atmosphere for a set range of altitudes and returns

the aerodynamic properties of the vehicle for each altitude. Because this model calls the

atmosphere of the chosen planet, Mars for this case, this is a fully viscous example of a trajectory

through an atmosphere. For the final vehicle, an angle of attack of approximately 7 degrees

provides the highest L/D for the mission, so flying at this angle of attack would be ideal.

Figure 6: Plot of L/D vs Altitude for various angles of attack

157

Figure 7: Comparison of Drag Coefficients

From Figure 7, one might conclude that the viscous interaction effects are indeed a major

factor on the aerodynamics of the vehicle and cannot be ignored. To further analyze the effect of

viscous interactions see Figure 8. Note that although the CD VI was relatively large at high

altitudes, the DVI was not. That is due to the fact that Drag is a factor of the density, so when the

vehicle is at high altitudes, the density is low, and therefore the drag is low. (Note that lift will

also be low at high altitudes). Figure 9 shows the percentage of each component of drag towards

the total drag. Note that the percentage of drag due to viscous interaction effects never dropped

below approximately 10 percent. This confirmed the suspicions that viscous interaction effects

could not be ignored.

158

Figure 8: Comparison of Drag Components

Figure 9: Drag Component Percentage

159

8.3 Overview:

The part of the MDO was to provide an analysis of the variable vehicle parameters and to

run the code developed by the other members of the group. Also, in the case that some part of the

design is not picked up by the other members of the group, the MDO is responsible for that part.

Although this paper is for the Mars MDO, much of this position was required for aerodynamics

analysis.

Analyzing the drag on the vehicle, the conclusion was drawn that viscous interaction drag

could not be ignored, and any further analysis of AGA maneuvers must make sure to take that

into affect.

8.4 Explanation of Code:

traj.f: The main program that computed the trajectory of the vehicle around a planet. The

original code was provided by S.P Schneider but was greatly modified. To accommodate running

many iterations, traj.f was changed to accept the vehicle parameters as inputs instead of the

parameters being hard coded in the traj.f script.

aerodat.f : The code that calculated the aerodynamics of the vehicle. This code was originally

provided by S.P Schneider to evaluate a flat plate using Newtonian Method and remains

untouched by the MDO.

atmo76.f: File that contains atmospheric data for Mars, including temperature and density versus

altitude.

160

altvmap.for: Code that analyzed a vehicle at a fixed angle of attack and for a range of altitudes

and velocities. Altvmap.for calls atmo76.f for atmospheric data. Originally provided by S.P

Schneider, altvmap.for was modified to accept the vehicle parameters, velocity range, and

altitude range as inputs.

aeroprop.for: Program that called aerodat.f and produced data for plots of stable xcg locations.

This program analyzed the inviscid case only.

Mars MDO created Scripts: All scripts created by the MDO for Mars contained a header such

that if the help function was used in MatLab, a description of the code and how to use it was

displayed. These headers are used for the explanation of the following scripts.

AeroInputMatrix_FPRINTF.m:

This code allows for iterations of aeroprop.for for one or more

changing vehicle parameters.

This will create a directory within the current working directory called

AeroPropEval. Within AeroPropEval, several Trial# directory's will be written,

each containing a range of vehicle parameters for a set vehicle length

So matlab does not have to be run through Unix, this program writes a

series of unix commands to a file that will run the iterations in unix.

161

To start the iteration process:

1. Run this script for the parameters to be evaluated.

-The Following Step Take Place In UNIX-

2. In order to execute the iterations, the file "runaim" must be

exectuable. To make "runaim" executable type: "chmod 700 runaim"

3. This script makes use of the a.out file that is written out when

aeroprop.f is compiled and linked. To compile aeroprop.f type: "runaeroprop"

4. Type "runaim" to start the iteration of aeroprop.f through

the specified vehicle parameters.

The iterations may take quite a bit of time if you make the vectors very

large.To save time decrease the number, n, of xcg locations analyzed.

Aeropropdata.m:

aeropropdata.m determines the number of "Trial" directories that the

current AeroPropEval directory has. For each trial, aeropropdata reads the

number of aeropropdata_* files that exist. For each file, the CL/CDmax and

xcg location of the CL/CDmax are found.

Within the script, plotlong must be defined:

If plotlong=0, then aeropropdata will output plots of Cm,cg versus angle

of attack for each xcg location examined. These plots are used to

determine if the vehicle is stable at the given xcg location. The vehicle

is stable if Cm,cg=0 and has a negative slope for a given flap angle.

If plotlong=1, then aeropropdata will output a single plot of CL/CDmax

versus the xcg location it corresponds to. This plot is useful because it

162

shows the range of xcg locations that produce stable trim, but also it

shows the xcg location that produces the maximum CL/CD for the vehicle.

AltVInputMatrix_FPRINTF.m:

This code allows the iteration of altvmap.for for a range of vehicle

parameters.

This will create a directory within your current working directory called

AltVEval. Within AltVEval, several Trial# directory's will be written,

each containing a range of vehicle parameters for a set vehicle length.



To start the actual iteration process:


2. In order to execute the iterations, the file "runavim" must be

exectuable. To make "runavim" executable type: "chmod 700 runavim"


altvmap.for is compiled and linked. To compile altvmap.for type: "runaltvmap"

4. In Unix type "runavim" to start the iteration through altvmap.f


large.To save time, decrease the number, n, of xcg locations analyzed.

163

Marsaltvmapdata.m:

aeropropdata.m determines the number of "Trial" directories that the

current AltVEval directory has. For each trial, marsaltvmapdata reads the

number of altvoutput_* files that exist.

For each file, marsaltvmapdata finds the CL,CD,L/D,CD_newtonian,

CD_skin_friction, and CD_viscous_interactions

Note: At very high altituded, CD due to viscous interaction is much

larger than the CD calculated from Newtonian method, and very much larger

than the CD from skin friction. This fact will greatly influence

atmosphere entry vehicles sizing and should be taken into account.

marsaltvmapdata analyzes the L/D at high altitudes, which is nearly

constant, and plots L/D versus plate length for varying angles of attack.

This allows for optimization for plate length and angle of attack.

TrajInputMatrix_FPRINTF.m:

This code allows for iterations of traj.f for one or more changing vehicle

parameters.

This will create a directory within the current working directory called

TrajEval. Within TrajEval, several Trial# directory's will be written,

each containing a range of vehicle parameters for a set vehicle length

164



To start the iteration process:


-The Following Step Take Place In UNIX-

2. In order to execute the iterations, the file "runtim" must be

exectuable. To make "runtim" executable type: "chmod 700 runtim"


traj.f is compiled and linked. To compile traj.f type: "runtraj"

4. Type "runtim" to start the iteration of aeroprop.f through

the specified vehicle parameters.


large.To save time decrease the number, n, of xcg locations analyzed.

Trajaerodata.m:

trajaerodata.m determines the number of "Trial" directories that the

current TrajEval directory has. For each trial, trajaerodata reads the

number of trajoutput_* files that exist.

For each file read, trajaerodata determines if the vehicle entered the

atmosphere. If the vehicle entered the atmosphere, trajaerodata

determines the CL/CDmax, xcg location of for the CL/CDmax case.

Within the script, plottype must be defined:

If plottype=0, trajaerodata plots CL/CDmax vs xcg for each xcg position

165

used. If the vehicle is not able to trim for a give xcg location,

CL/CDmax=0.

If plotlong=1, trajaerodata plots CL/CDmax vs angle of attack for

each vehicle length analyzed.

SPSMars.m:

SPSMars loads the output from traj.f for a specified trajoupt_* number.

To find the correct trial number to read in, such that the vehicle is

trim, run trajaerodata.m to find the range of stable xcg locations, then

find the trajinput file that produced a stable xcg location. Use the number

of that the trajinput file to run SPSMars.

SPSMars will read in each of the for output files for the given trial:

%%% trajoutput_#.aer %%%

SPSMars determines if the vehicle entered the atmosphere. If the vehicle

entered the atmosphere, SPSMars plots the CL versus time, CD versus time,

and the CL/CD versus time.

%%% trajoutput_#.out %%%

SPSMars plots the Altitude, Flight Path Angle, Longitude, and Latitude

versus time.

%%% trajoutput_#.qw %%%

166

SPSMars determines if the vehicle entered the atmosphere. If the vehicle

entered the atmosphere, SPSMars plots the heatflux versus time for each

of the points on the vehicle heatflux data was taken. NOTE: For high

altitudes, although the vehicle is in Mars atmosphere, there may be no

heatflux. This may be an error with the Heatflux.for code.

MarsAtmoData.m:

MarsAtmoData plots the Temperature and Density of Mars atmosphere versus altitude

167

Reference

[8-1] Methods for Analysis of Preliminary Spacecraft Designs, AAE450, Spacecraft Design,

Purdue University; S.P. Schneider, August 5, 2005

168

9 Venus Multidisciplinary Design Optimization – Rob Fink

9.1 Overview

Initially, the job of optimizing the aero gravity assist mission, specifically in this case

through the Venus stage, involved design parameters of the vehicle (dimensions, mass),

aerothermodynamics (heat flux, stagnation point temperature and associated thermal protection

system, or TPS) and aerodynamics (angle of attack, roll angle). Optimization occurred through

multiple iterations, from the beginning stage when initial codes analyzed a crude prototypical

spacecraft that was a blunt, flat plate up till the end, with the vehicle’s final basic design, a

wedge, incorporated its particular aerodynamic characteristics into the analysis. Furthermore,

the Venus MDO iterations used a trajectory system developed by the team member in charge of

implementing the proper trajectory through the Venusian atmosphere, and analyzed the

spacecraft’s performance via output data that included lift, drag and heat flux (among others, but

these three were initially and, in the case of the former two, eventually the primary concern). In

a given iteration, the output data was plotted graphically for the given stage and interpreted as

such. It is important to note that each iteration had to be isolated from the previous or the next

iteration, as the trajectory’s control was attuned to the vehicle’s size/dimensions to execute a

proper aero gravity assist as per given initial and final conditions, and that any given analysis

only attempted to predict trends from that particular stage of the iteration. This is to say that

while a general overall trend could be speculated, it could not be satisfactorily determined from

the outset or in the middle of the design process. In metaphorical terms, this meant hiking one or

maybe two steps in any direction rather than laying down an entire path to a particular

169

destination; such is the nature of the iterative process, as cumbersome or inefficient as it may

seem.

In the beginning the blunt, flat plate was used for analysis, and it took place in the Earth

atmosphere. The idea behind this initial analysis was to find out whatever important overriding

concerns arose when tampering with vehicle dimensions and aerodynamic parameters.

Conclusions based on this early vehicle were too premature because the design was crude, since

it was known early on this would not be the final design, raising particular concerns of mass

properties, since the structure design specifics (e.g. mass, TPS) were arbitrary at that point.

When the basic shape for the SPEAR was introduced in the aerodynamics code, a greater

understanding of the prevalent issues began to form. Whereas it was speculated early that the

amount of TPS - affecting aerodynamics and vehicle mass considerations - would be the main

concern, it became clear that it was not; in fact, the amount of lift over drag generated by SPEAR

was not enough for the mission requirements. Therefore, iterative analysis became focused on

how to change parameters to cause greater lift and decrease drag.

Finally, it should be also noted that the conditions of Venus’s atmosphere are greatly

different than Mars’s or Earth’s, inducing a wrinkle in the optimization process that causes

tradeoffs in the size iterations between the different stages of the mission. Venus has a very

dense atmosphere, prone to induce greater drag on a spacecraft. The slight bonus was that

nothing about Venus’s notoriously high temperatures, produced by the Greenhouse Effect,

created any heat flux concerns.

170

9.2 Blunt Flat Plate Analysis

Included as a prelude to the actual proposed wedge design, the blunt flat plate (BFP) was

an important early analysis to try and predict trends. While not very precise or clearly helpful in

identifying guiding sizing parameters for the wedge design, the BFP was needed to evaluate

aerodynamic capabilities and try to find important trends in aerodynamic and

aerothermodynamic performances. The first thing to do was change certain parameters to see

response in performance, while keeping others constant. Parameters that were kept constant

were flight path angle (important to trajectory but incidental to aerodynamic performance),

vehicle mass (early response from changing mass of BFP showed little/no change), vertical

center of gravity location (assumed to be zero, lying dead center, vertically, of BFP), specific

impulse (ISP, had no effect on aerodynamic performance) and angle of attack (to be analyzed at

a later time). First tests were done changing the nose radius over a range of values: 0.002m,

0.005m, 0.010m, and 0.100m. The following parameters were held constant: plate length =

10.0m, flap chord = 2.0m, width = 2.0m, axial center of gravity = 5.7m (from the nose back,

minus the nose radius) and angle of attack = 7 deg. Using the traj.f FORTRAN code to compute

aero data, the following three plots generated from Matlab show typical output that was to be

analyzed:

171

100 150 200 250 300 350 4000

0.5

1

1.5

2

2.5

3

3.5x 10

-3 Lift Coefficient vs. Time

Time (s)

Lift

Coe

ffici

ent

Figure 10 – Lift Coefficient vs. Time

Figure 10 shows a typical response of lift coefficient versus time since the angle of attack

was never varied from seven degrees (this is simply to show that the values were successfully

outputted given the parameters).

100 150 200 250 300 350 4000

0.002

0.004

0.006

0.008

0.01

0.012

0.014Drag Coefficient vs. Time

Time (s)

Dra

g C

oeffi

cien

t

172

Figure 11 – Drag Coefficient vs. Time

In Figure 11, we see a peculiar curve that represents the total drag over the course of the

flight. It was never determined what exactly caused the variance of drag in this case, but it

highlights an important issue that in case of such an anomaly, measures must be taken to find

what causes the variance and be able to account for its presence.

100 150 200 250 300 350 400-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1L/D vs. Time

Time (s)

L/D

Figure 12 - Lift over Drag vs. Time

In this plot, one can see the total lift over drag for the duration of the flight. It accounts

for the anomalous drag curve shown in Figure 11. The max L/D achieved is less than one,

which was unacceptable for any portion of the mission in atmosphere (Venus’s or the others’).

Subsequent increases of nose radius showed increased drag, of the same odd curve seen in the

figures previous. While such a result was rather obvious, the real missed opportunity would

have been to gain a better understanding of the dynamics of drag on the vehicle shown.

173

The second set of tests were done changing the vehicle size, from a larger overall area to

a smaller overall area. While the flap chord and width were changed proportionately, the length

was not, so the differences between big and small were not consistent, with the exception of the

placement of the axial center of gravity (which had to be adjusted proportionately to the plate

length). Results in either case were unremarkable, as the lift obviously did not change over the

previous trials (again, the angle of attack was not changed), only the drag was analyzed and the

difference was negligibly small. One lesson learned in this case perhaps was that the sizing had

to be altered more consistently, or more carefully as it may be more comprehensive to change

one size parameter at a time so as to find out what the effect of just one change would do to the

vehicle.

Additionally the early iterations were founded on the BFP as it was time for the team to

practice the iterative process and move the analysis forward from its infancy stages. This

included incorporating Venus atmospheric data to better simulate the mission. While the first

iteration was an unsuccessful run under the initial conditions, it provided early heat flux results

for TPS analysis. This was instrumental in gaining a better insight into the amount that would be

needed for the complete mission.

9.3 SPEAR Analysis

Once the aerodynamics of the new wedge shape was written into the code, better analysis

could take place and the iteration process could really shift into high gear. Part of this was

because real analysis of the wedge size could be used, giving indication as to whether increasing

or decreasing some parameter made all the more difference. Also, the trajectory control was

174

iterated and adapted to the shape to match the needed conditions, so the aerodynamic

performance was much more sensitive to changes.

The iterations began with aerodynamic analysis of preferred center of gravity locations.

This was important to the systems engineer, who in turn needed to position the “innards” of

SPEAR to reflect this range. Size parameters were more or less defined by the systems engineer

who fit the craft to the necessary instruments, engine, and power supply needed to operate the

spacecraft (aforementioned “innards”). Cutting down size was already an assumed desirability,

to reduce cost (in terms of mass) and surface drag. Optimization was utilized to take the initial

parameters set and try to find better performance by changing the size of the vehicle in certain

ways, either by lengthening the plate or shortening the width, and so on. Performance could

include everything from matching needed exit velocities, to adequate planetary turn arc

(sufficient duration of time completed through atmosphere for AGA), to possible aeroheating

issues, to lift over drag. Some parameters, as before with the BFP, were left alone as they

affected trajectory and were beyond the scope of optimization capabilities or had little to no

effect on performance.

One very key consideration that was an issue to begin with and dropped during this stage

was over the amount of heat flux. It was determined early on in the final wedge iteration stages

that the TPS necessary to keep SPEAR intact was much less than anticipated, and thus any

fluctuations in mass to reflect any size changes were fairly negligible with respect to the rest of

the spacecraft.

On the other hand, the greater issue arose with the lift over drag performance. Initial

estimates of the mission placed need of L/D values above three; however, in each stage of the

175

mission the values were barely above one. Various attempts were made on behalf of the Venus

stage, as well as the other two stages, to find solutions to this problem.

9.4 Conclusions

An attempt at a partial solution was found in reducing the nose radius, to the extremely

small value of one millimeter (0.001m) as a way to effectively decrease drag, improving the max

L/D value. Also, trends (and predictions) indicated a narrower vehicle to generate less drag (less

profile size), although this was largely unchangeable due to the sizing restrictions set by

SPEAR’s inner contents.

The only other importantly deciding factor in increasing lift over drag for the Venus stage

was to find an optimal altitude to minimize drag. During the Mars stage of the mission it was

determined that flying at a lower altitude was advantageous, however this produced no

advantages whatsoever for this stage, due to Venus’s incredibly dense atmosphere. In fact, there

is less drag involved flying through Venus at higher altitudes where the density decreases as one

ascends the atmosphere. Since this drop in drag is not sufficient enough to increase L/D where it

was needed to be, it was left up to the trajectory specialist to choose

The following graph shows the L/D performance for the last iteration, which was most

likely indicative of the best result possible:

176

0 100 200 300 400 500 600-1

-0.5

0

0.5

1

1.5

2L/D vs. Time

Time (s)

L/D

Figure 13 – Final Lift over Drag vs. Time

0 100 200 300 400 500 6000

50

100

150

200

250

300

350

400

450

500Altitude vs. Time

Time (s)

Alti

tude

(km

)

Figure 14 - Final Trajectory Result

Figure 14 shows the trajectory reached through the final iteration. Between the two it is

shown what L/D is over the portion of interest, between where t ≈ 190 sec and t ≈ 360 sec,

177

basically where level flight occurs. Before and after this period, SPEAR is in atmospheric

descent and ascent mode, respectively, and there is no concern over L/D effectiveness here.

The table below shows the associated values for the above plots (which are the final

dimensions reached at the conclusion of the iterations) as a reference. Those values which were

null or inconsequential to the optimization process were left out (ISP, extension, transverse cg -

center of gravity across the width of the vehicle).

Table 3 – Final SPEAR DimensionsMass(kg)

PlateLength

(m)

FlapChord

(m)

PlateWidth

(m)

NoseRadius

(m)

AxialCG(m)

VerticalCG(m)

WedgeAngle(deg)

365 3.575 0.25 1.25 0.001 2.022 0.028 4

While it is unfortunate to remark that certain conditions of the mission may not be

possible, the lessons learned during the iterative process were important. For one, even when

certain parameters are thought to be set in stone, it may be necessary to attempt a change, no

matter how difficult such a change would be to make in the real world, in order to find other

possibilities. Also, discovering when certain parameters cannot be optimized enough, it may be

indicative of the need to change the initial mission conditions in order to make the mission

feasible. In the case of this mission, more research and information needs to be done on flight

capabilities and aerodynamic theory in Venus atmosphere, a scenario which has numerous

difficulties in understanding and adapting, as has been shown.

178

10 Earth Multidisciplinary Design Optimization – Tim Kite

10.1 Introduction

The final part of SPEAR’s mission is sample return. In this case, it involves the

re-entry of the sample collection containers through Earth’s atmosphere to be collected on the

surface. The simplest way to accomplish this goal is to land the entire spacecraft much like the

Space Shuttle or X-23 following an atmospheric re-entry maneuver. In this preliminary design

phase, design parameters were defined, a trajectory and control system developed, and all aspects

were then optimized in an iterative manner in conjunction with the other design areas to better

meet the defined design parameters. This section of the report will examine in detail the design

parameters used, team interaction and interdependency, design methodology (including

trajectory and control law theory, development, and optimization), the results obtained through

the iterative design process, and will conclude with a discussion of how these preliminary results

impact the possibility of mission completion.

10.2 Assumptions

The assumptions used during the Earth re-entry design are:

When changing trajectories in interplanetary space, the angle changes are small Bank angle was controlled by RCS system Angle of attack was controlled primarily by single flap Changes in ΔV are assumed instantaneous Changes in bank/pitch are assumed nearly instantaneous in comparison to the time step used Cg location was impacted only negligibly due to RCS use during flight Other, more specific assumptions are mentioned within the simulation code comments

179

10.3 Design Parameters

The goal of the Earth design was to determine if it is possible for the same craft

optimized for both Mars and Venus would be able to successfully land on Earth without

requiring any modifications that would pull the craft away from its optimized solution. As such,

Earth optimization was largely a trajectory and control law optimization problem, with vehicle

dimensions left the same and the weight and center of gravity adjusted for the fuel burnt during

the mission.

A successful re-entry is one that keeps G-forces below prescribed limits for the structure

and any payload present, keeps heating below levels which can be withstood by the remaining

available TPS and which don’t raise the internal temperatures above the operating level of the

on-board instruments with the given insulation. The re-entry also must be a controlled decent

such that it results in either a controlled glide which could be landed or a velocity low enough for

parachutes to be deployed, since with the RTG on-board SPEAR will have to land rather than

splash down. Finally, the re-entry trajectory cannot exit back out into space during decent, as

that would result in several alternating periods of heating and cooling, adding unnecessary

complication to the TPS and heating calculations. Because SPEAR is a lifting body, this implies

a glide re-entry as defined by Tauber and Yang [10.3] (p. 265).

10.4 Team Interaction and Interdependency

Nearly all the initial states of the variables used in the Earth re-entry trajectory design

phase were determined by other team members or resources external to the team. As given in the

methods handout, trajectory depends on aerodynamic performance parameters (especially the

stable angle of attack range) determined by aerodynamics, permissible surface temperatures

180

determined by aeroheating, permissible TPS ablation levels determined by TPS, and the amount

of positional and directional control available as given by propulsion and aerodynamics. Also,

aerodynamic parameters are dependant on vehicle shape, mass, and center of gravity location, as

determined by systems design. Additionally, because the goal of Earth re-entry is to see if re-

entry is feasible given a spacecraft optimized for Mars and Venus, the allowable loads

determined by structures are also a factor limiting the re-entry trajectory.

These inputs are not one-way, however, since the entire design process was iterative.

Successful Earth re-entry requires SPEAR to fly at a much higher angle of attack than for Venus

or Mars because at Earth the goal is to slow down and land rather than change course. As such,

the allowable range of Cg locations which could result in high enough stable angles of attack for

Earth re-entry had to be determined. Because SPEAR’s fuel could not be placed around its

center of gravity, the Cg changed between Mars, Venus, and Earth flights, requiring a happy

medium to be determined which would allow all three trajectories to work. Also, because re-

entry into Earth’s atmosphere burned off some additional TPS and caused structural heating, TPS

and insulator thickness had to be adjusted to be adequate for the entire mission, which in turn

changed the mass of the spacecraft. These interdependencies necessitate including parameters

from Earth in the optimization of the entire mission, which could have potentially made the

mission impossible, but in the end did not.

10.5 Design Methodology

Because this was an initial design, a basic trajectory simulation code had to be developed.

This code would allow input of the various variables and constants and would output the results

of the given spacecraft flying the given trajectory. Because the Earth re-entry trajectory

181

followed the same logic and equations as the Mars and Venus trajectories, differing only in final

state and control scheme required, the code used was drawn from that developed for the Mars

and Venus trajectories and modified to fit Earth.

10.5.1 Trajectory Theory and Development

A standard planetary re-entry would involve a spacecraft in low orbit performing a retro-

burn to lose enough speed to enter the atmosphere. The burn would be calculated such that the

flight path angle at atmospheric entry, as measured from a plane tangent to the atmosphere,

would be in the range of -1.5 to -3 degrees, as defined in the methods handout. This low of an

entry angle coupled with a high L/D vehicle would result in something between a gliding flight

path and a skipping re-entry, as defined by Tauber and Yang [10.3] (pp. 264-265), which is ideal

for most re-entry situations including the Space Shuttle.

SPEAR did not re-enter from low Earth orbit, rather, it had a hyperbolic trajectory.

Because of this, SPEAR also had a much higher velocity at atmospheric entry than the Space

Shuttle. Initial conditions for this trajectory were found by Tracy Smith, a resource external to

the team, and published in a paper titled “Aerogravity Assist Trajectories for Mars-Venus

Sample Return Missions” [10.2] (p. 5). Initial values for Earth Arrival from this paper are shown

in Table 4 below.

Table 4: Given Arrival ConditionsArrival Date July 3, 2017

V∞+ 2.53511877461x – 0.1965298704y – 1.6167828300z

Initial Radius 7278.13 kmInitial Inertial Velocity 10.8910 km/s

Initial Flight Path Angle -8.5611755 deg

182

Based on the iterative simulation analysis, these given conditions do not result in a re-

entry (in fact, they don’t even approach the atmosphere). Because of this, they needed to be

adjusted so that a re-entry was possible. The simplest method of accomplishing this would be to

change the initial flight path angle to point more at the planet. This would necessitate a change

in initial flight path angle to -21.0065 degrees (for the final iteration), a change of about -12

degrees. Based on Equation 4 below and taking both V1 and V2 to be equal to the given initial

velocity, this would involve a ΔV of 2.36 km/s, far outside the realm of possibility, especially

considering SPEAR only carried fuel enough for 300 m/s of ∆V and the Earth re-entry portion of

the mission was only given 100 m/s of that.

Equation 4: Law of Cosines

Another solution would be to perform a maneuver at a location very distant to Earth

while en route from Venus to change the value of the initial radius. Because the angular change

required is much less (by several orders of magnitude), this maneuver would be possible.

To determine the new initial radius required, an iterative solution was used. By setting

the initial velocity and flight path angle to those given and the latitude, longitude, and heading to

arbitrary values as defined later, the initial radius could be determined by decreasing it (because

it was overshooting Earth) until re-entry was successful. During these re-entry attempts the

angle of attack was locked at the maximum stable value and the bank was inverted to produce a

negative lift vector. For the final iteration, this resulted in an initial radius of 6604.51 km, a

change of 673 km. Using Equation 4 again, except this time with the angle unknown and the ∆V

set to half of that allotted for Earth (50 m/s), the change in direction would be about 0.263

degrees, which is a fair approximation because the angle is small. Assuming inertial space with

183

negligible gravitational influence (as in interplanetary space) and a small angular change, and

using Equation 4 again, except using distances instead of velocities, the required distance from

Earth to perform the maneuver would be about 146593 km. Performing the maneuver further

away would result in an even smaller required ∆V.

With the initial trajectory determined, the flight path through the atmosphere then needed

to be determined. This flight path should seek to minimize deceleration forces and heating,

while not skipping off the atmosphere as defined earlier in the design parameters. The initial

controller did not use a trajectory once in the atmosphere, and early controllers used only a single

target cruise altitude. It was found through experimentation, though, that these did not allow the

controller to meet the re-entry design requirements. It was found that a similar flight path was

followed by the X-23 PRIME test vehicle [10.1], which followed what could be approximated as

a 3-part re-entry path starting with a decent phase, followed by leveling off or rising slightly as

the atmosphere becomes thicker, followed by another decent phase until transition to supersonic

speeds was reached, which ended up becoming the in-atmosphere trajectory of the final

controller. Stopping the simulation when hypersonic flight ended was necessary because only

the equations for Newtonian hypersonic flight were used (as defined in the methods handout) as

the equations needed to simulate the remainder of the flight are beyond the scope of this course.

The 3-part flight profile was used because it most closely approximates the flight path necessary

for a constant deceleration while re-entering the atmosphere. The exact angles and intercepts

defining the flight path were determined experimentally every iteration to minimize deceleration

force.

The flight profile resulting from this is near optimal, but results in a flight path angle at

atmospheric entry between -4 and -5 degrees. According to the methods handout, this would

184

produce excessive heating, but thanks to the 3-part flight profile, SPEAR slowed down

sufficiently in the thin upper atmosphere that this did not occur. A shallower flight path ended

up not being possible because the speed was so great that any less of an initial angle and the craft

just flew through and out of the atmosphere, even upside-down and at maximum angle of attack.

The only arbitrary (not calculated directly from some other parameter) values used in the

trajectory design were the initial longitude, initial latitude, and heading. Due to some unresolved

divide-by-zero problems in the trajectory analysis code, equatorial flight was not possible.

Instead, these values were chosen to point SPEAR at the South-Western United States after the

re-entry maneuver was complete, since it had to land rather than splash down due to safety

concerns with the RTG and the desert is a great place to land a potentially dangerous space craft

due to large, flat areas and lack of population. The final result was a course that pointed more or

less at Texas, but that could be adjusted easily by changing one, two, or all three of the arbitrary

parameters to select a different landing site.

10.5.2 Control Law Theory and Development

Having a good trajectory is meaningless if the spacecraft doesn’t follow it. SPEAR could

be controlled by its RCS system throughout the flight and then additionally by its flap once in the

atmosphere, where control, rather than just trajectory, matters. In the methods handout, a basic

PID controller which modulated bank only and held angle of attack constant was described. The

proportional control would change bank to create positive lift if the craft was below some target

altitude, and would create negative lift if above the target altitude. Damping was added with

derivative control based on the rate of altitude change, and integral control could be added,

though it wasn’t recommended as it would generally cause system instability. The basic

185

equation for a PID control law is shown below in Equation 5. Here, u(t) is the control effort,

which is added to the current bank angle to produce the resulting bank after control. Also, e(t) is

the error signal and kp, kd, and ki are the proportional, derivative, and integral gains, respectively.

Equation 5: Basic PID Control Law

The first control law tried for Earth re-entry was quite different from this. It was a PD

controller (ki = 0) which modulated angle of attack based on velocity and acceleration and only

altered bank angle to weave left and right to lose more energy than a steady flight would. The

reasoning behind this was that at such high entry angles, positive lift would be needed at all

times to keep SPEAR from crashing. Also, acceleration was used as a control parameter as it

was to be minimized. This did not actually work, though, as it tended to produce a skip

trajectory as seen in Figure 15 below. When the trajectory was forced to remain within the

atmosphere via careful modulation of the entry angle and controller gains, as seen in Figure 16,

the deceleration forces encountered were high enough to require changes to the spacecraft

structure, a result that was undesirable as it affected the mission negatively.

186

0 500 1000 1500 2000 2500 3000 3500 40000

1

2

3

4

5

6

7

8

9x 10

5

Time (seconds)

Alti

tude

(met

ers)

Altitude vs. Time

AltitudeEdge of Atmosphere

Figure 15: Example of Skip Trajectory

0 100 200 300 400 500 600 700 800 9000

1

2

3

4

5

6

7

8

9x 10

5

Time (seconds)

Alti

tude

(met

ers)

Altitude vs. Time

AltitudeEdge of Atmosphere

Figure 16: Example of Successful Velocity Controller

187

This type of control obviously wasn’t ideal, so a new controller based on the 3-part

altitude curve was then developed. Like the example controller, it modulated bank to maintain a

desired altitude. This controller also had control over angle of attack, though, as that would

provide finer control of the rate of decent. While the entire commented code for the finished

controller can be found in the Control Law section of traj.f on the program code CD, the basic

control law logic is as follows:

SPEAR began re-entry inverted and at maximum stable angle of attack Once a low enough altitude had been reached for the controller to be effective, it was switched on If SPEAR was above the target altitude, the proportional controller would cause the bank to tend towards inverted, producing negative lift. If it was below, the bank would tend towards positive lift. Angle of attack was used to modulate rate of change in altitude, based on derivative control and the size of the error signal Integral control was used only slightly to reduce steady state error, and affected the angle of attack All gains were determined experimentally

The resulting final controller produced results as seen in Figure 17 below. The controller

actions (bank and angle of attack) for all iterations are available in Appendix B.

188

300 400 500 600 700 800 9000.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10

5 Altitude vs. Time

Time (seconds)

Alti

tude

(met

ers)

AltitudeEdge of AtmosphereControl Altitude

Figure 17: Example of Course from Final Controller

10.5.3 Optimization Method

The trajectory optimization process for each rendition of SPEAR followed a logical

process to determine each of the unknowns experimentally. First, the initial radius from Earth

was determined by flying at a constant inverted bank at maximum stable angle of attack. The

goal at this phase was to produce a trajectory with minimal entry flight path angle and a course

that leveled off rather than trying to skip up. Once this was determined, the angles and intercepts

of the control altitude lines were selected to match the natural course with minimal turning to

minimize G-forces. The final leg had a smaller slope than the natural slope so SPEAR would

enter a glide upon exiting hypersonic flight at the end of the simulation. Since the controller

gains were optimized previously during controller creation, only these angles and intercepts had

189

to be tweaked to produce an optimal re-entry path. The results of the heating simulation were

then sent to TPS to adjust the required TPS for the next iteration and the loading results were

sent to structures.

10.6 Iterations and Results

As stated before, SPEAR itself was designed using an iterative process. Each step, based

on inputs from all design areas, altered the dimensions and other characteristics of the vehicle

toward the final design. The course of these changes is outlined in (reference) below. Note: For

Iteration 7, the dry (no fuel) values for mass and Cg were calculated for Earth. All other

Iterations used the same values on all three planets. Values marked in red were altered to allow

stable Earth re-entry on that iteration. Iteration 3 was abandoned because the Mars and Venus

missions failed.

Table 5: Vehicle Parameters for EarthIteration # 1 2 3 4 5 6 7

Plate Length [m] 5.558 3.825 N/A 3.050 3.524 3.575 3.575Extension Length [m] 0.300 0.300 N/A 0.300 0.300 0.300 0.300

Flap Chord [m] 0.250 0.250 N/A 0.250 0.250 0.250 0.250Plate Width [m] 1.632 1.644 N/A 1.233 1.233 1.250 1.250Nose Radius [m] 0.005 0.005 N/A 0.005 0.001 0.001 0.001

Included Wedge Angle [deg] 8.000 8.000 N/A 5.000 4.000 4.000 4.000Axial Cg Location [m] 2.966 2.20 N/A 1.678 1.920 1.970 1.985

Vertical Cg Location [m] 0.014 0.0017 N/A 0.026 0.024 0.027 0.030Vehicle Mass [m] 527.0 536.0 N/A 232.0 286.0 366.0 325.0

For the first iterations, the controller was completely angle of attack based. Though the

re-entries met the requirements for heating, deceleration forces, and end state, the heating was

uneven. This was due to the tendency to skip and therefore the TPS usage was difficult to

analyze properly. These were iteration ‘0’, though, and did not influence vehicle design, only

190

controller design. See Figure 15 and Figure 16 above for examples of this preliminary

controller.

For iterations 1 through 7, the altitude controller in varying stages of completeness was

used. Also, the wedge code was used, so these iterations represent as accurate a simulation as

possible. In some cases, the Cg location given by systems and verified by aerodynamics resulted

in an insufficient stable angle of attack range, so a different Cg location had to be selected.

Later, at iteration 6, it was discovered that these discrepancies were due to an error in the

aerodynamics code, which was fixed for iteration 7, so prior to this the stable ranges were not

accurate, though this did not affect the ability of SPEAR to re-enter Earth as fixing the code only

increased the size of the range, it didn’t change it. The changes in the stability ranges can be

observed by comparing the stability range from the earlier iterations to that from iteration 7.

These plots are available in Appendix B. The stable range is marked by a vertical black line on

the maximum angle of attack and another on the minimum angle of attack if it isn’t just the

wedge angle. A Cg location is stable when the moment coefficient is zero with a negative slope.

After optimizing the controller each time, the heating data was sent to TPS for analysis

and the G-force loading data was sent to structures. The plots for the stagnation point

temperature (a simplification of the entire heating data file) and the loading are also available in

Appendix B for all iterations.

On the final iteration, the landing area was computed. This was done by creating 4 plots

with the same vehicle. One where the bank angle oscillated from left to right during the decent,

losing as much energy as possible as quickly as possible without taking too much loading, and

finding the shortest flight path. Running the simulation again without the weaving resulted in the

longest flight path. To find the side-to-side range, right-banking and left-banking trajectories

191

were also run. These four were then plotted together, and can be found in Figure 19. The area

outlined is not actually the landing area, but rather the area over which the craft can be made to

transition from hypersonic to supersonic velocities. The arrows indicate that SPEAR would

continue gliding further to finally land, possibly in Texas or somewhere else in the south-western

United States. The final trajectory is shown in Figure 18.

50 100 150 200 250 300 350 400 450 500 5500.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10

5 Altitude vs. Time

Time (seconds)

Alti

tude

(met

ers)


Figure 18: Final Re-Entry Trajectory

192

226 227 228 229 230 231 232 233

15.5

16

16.5

17

17.5

18

18.5

19

19.5

Range at Hypersonic Speeds

Longitude (degrees East of Prime Meridian)

Latit

ude

(deg

rees

nor

th o

f Equ

ator

)

Shortest Range (weaving)Left-most RangeRight-most RangeLongest Range (steady)

Figure 19: Hypersonic Exit Area

10.7 Conclusion

Direct re-entry of SPEAR through Earth’s atmosphere to land on the ground turned out to

be quite possible. The final optimized trajectory met all the requirements for deceleration

loading, heating, TPS usage, landing area, and simplicity of trajectory. It also did so reliably

even when an incorrect stable range of angles of attack was provided. Though the re-entry

would be more ideal if the velocity was lower at atmospheric entry (so the entry angle could be

made less), it was still possible to re-enter without excessive heating, contrary to initial

speculation from the methods description. In the end, the Earth re-entry phase of the mission

was not only successful itself, but it also was successful without hindering the Mars and Venus

phases of SPEAR’s mission.

193

10.8 References

[10.1] Meltzer, J., Rossoff, J., and Slaughter, J. I., “Structure and Materials Aspects of

the PRIME Flight Test Vehicle”, El Segundo Aerospace Corporation, December 31, 1965

[10.2] Smith, Tracy, “Aerogravity Assist Trajectories for Mars-Venus Sample Return

Missions”, October 2005

[10.3] Tauber, Michael E. and Lily Yang, “Performance Comparisons of Maneuvering

Vehicles Returning from Orbit”, NASA Ames Research Center, Moffett Field, California, July –

August 1998

194

11 Systems Engineering – Michael Moessner

11.1 Introduction

The first step in the systems portion of the design process was to determine spacecraft

components necessary to meet mission requirements. Scientific components, propulsion, data

communication, avionics, instrumentation, and power components would be necessary to

complete the mission. The wedge shape decided on made the location and sizing of all

components difficult for several reasons. The wedge did not allow any components to be placed

far forward since the internal height was too small. This issue was exacerbated over the course of

the design process, as the wedge angle became continually smaller causing the amount of empty

space in the forward section to increase. Also, the components were chosen based on the initial

assumption that they should be as light and small as possible. Small size remained important

through the design process, but the small mass did not. As the iterations went forward, it became

necessary to increase the mass of the spacecraft in order, to get a better ballistic coefficient

trajectory and to decrease the angle of the wedge in order to fly at smaller angles of attack.

11.2 Components

The only scientific component for the mission is the scoop used to collect atmospheric

samples. The GCMS used in the Huygens spacecraft was chosen although it not only collects but

analyzes the samples as well. The dimensions for the scoop were 200 x 200 x 206 mm and it had

the mass of 6.7 kg. Two scoops were installed for redundancy. Four sample containers were

added in order to provide storage for the atmospheric samples obtained by the scoop. It is

possible for more storage containers to be added if deemed necessary.

195

The components for propulsion include the thrusters and tanks provided in the Propulsion

section. The total mass of propellant was about 40 kg by the last iteration. The tanks were sized

using a program provided by propulsion. Current mass of the spacecraft was input and mass of

propellant was outputted by the program.

The data communications for the spacecraft did not need to be very powerful since only a

small amount of data needed to be transferred back to Earth. The AeroAstro X-Band

Transponder was chosen. The dimensions of the transponder are .1524 x .0762 x .0762 m and

had the mass of 850g. An AeroAstro S-band transmitter, receiver was also chosen to make

communications possible over a larger range of bandwidths. The S-Band transmitter is .025

x .076 x .051 m, and the mass is .2 kg. Although the transponder and transmitter may not be

powerful enough for Spear’s mission they are a minimal size for estimation. Antennas should be

added in future, but were neglected for simplicity.

The computer chosen was as the AeroAstro MicroCore Avionics Module. The

dimensions of the avionics module are 30 x 28 x 17 cm and mass of 12.7kg. It was chosen based

on the assumption that this mission will require only a small amount of computing power and

that its small size was more important. A larger more powerful computer may become necessary

if computing power becomes more important in the future designs.

The positioning instrumentation chosen was the AeroAstro Miniature Star Tracker and

AeroAstro Medium Sun Sensors. Positioning instrumentation maybe needed for maneuvers. The

dimensions of the Star Tracker are 5.4 x 5.4 x 7.6cm, and the mass is 300 grams. The miniature

star tracker was chosen since it and seemed to be a good minimum range of the technology, and

more importantly for its small size. The AeroAsrto Medium Sun Sensors added to gain higher

positioning accuracy. There were 3 sun sensors added, each with a mass of 36 g 3.5 cm in

196

diameter and a height of 1 cm. The mission may or may not require more exact positioning but

the minimum size of the star tracker and sun sensors were determined to be more important for

the current iterations.

The linear motor chosen to operate the flap was the Aerotech BLMH Series Linear

Motor. Its mass is 4.376kg and is .051 x .36 x .087m. It is capable of a continuous force up to

822N, and a peak force of 3288N. A single motor may not be able to move the flap, but using

two motors should be sufficient. The Linear Motor was chosen mainly as a placeholder, in mass

and size for a more space worthy and lower power method of controlling the flap.

The power for Spear was originally provided by a General Purpose Heat Source

Radioisotope Thermal Generator, used in Cassini. This power source was chosen since it can

provide 570W at launch. The dimensions of the GPHS RTG are 114cm in length and have a

diameter of 42.2 cm; it has a mass of 56 kg.

Figure 11.1

197

Figure 11.1 shows a diagram of the RTG. After several iterations the RTG was linearly

scaled down to reduced the size. The power requirements now for the first time became a

concern. The volume of the original RTG was .159m^3, and provided 570 W of power. Power /

Volume = 3580 W/m^3. The new volume was .02m^3 giving a new power of about 71 W. This

is just adequate so long as the linear motors and X-Band transponder are not on at the same time.

An assumption was made that data transmissions in the atmosphere would be difficult, so the

communications would not be on. The avionics require 50W leaving 21 W for the linear motors

and gyros. Since the RTG from Cassini was old a smaller more powerful RTG should be

researched or found for the mission. The position of the RTG for the final iteration was chosen

based on size only. The location, butted up against the back wall and the avionics module, is very

poor. On Cassini the RTG was on the end of a boom and shielded, this is shown in Figure 11.2.

Shielding will need to be added to protect the other components for the RTG.

Figure 11.2

198

Its present location in Spear may require that the power source choice be reexamined.

Battery power may be sufficient if the spacecraft could be shut down or put into stand by for the

crossing portion of the mission and only activated when entering the atmosphere. Solar power

would only be applicable if a large complicated solar array could be packed and deployed from

inside Spear. A locked solar array, found on most spacecraft, could not be deployed during the

atmospheric maneuvers. Iteration 8 was started to deal with this problem and dealt with systems

only, it was not analyzed.

The nose is made of high temperature ceramic to protect the spacecraft from heat.

Originally attempts were made to reduce the mass of the nose. Eventually the size and mass were

increased to move the center of gravity. By the last iteration the mass overpowered the good it

did for the center of gravity. The mass however was needed, to improve the ballistic coefficient,

so was left in. The density, according to the methods hand out, was between 4.44 to 10.95 gm/cc.

A value of 6800 kg/ m^3 was chosen not for its material characteristics but to correct the cg

location. This density gave the nose the mass of 74kg, which produced the desired cg location.

This may not be right and should be examined again in a more detailed design.

An ablator and insulator was used to protect Spear from the high temperature it would

experience in the atmospheric maneuver. The thicknesses were obtained from TPS and their

masses were determined by the shape and size of the iteration.

Parachutes were added mostly to more accurately model the mass and the center of

gravity of Spear. The mass was obtained from a Mars entry vehicle. This may not be a

reasonable assumption for Spear, since the parachute was to be deployed in Earth and not Mars.

The parachute will need to be reexamined in future development. There were two main

parachutes each .5 x .3 x .1m and 24 kg. There was also a drag chute, with a size of 15 x .2 x .4m

199

and a mass of 19kg. They were added as an estimation of the necessary components weight and

volumes that were neglected.

The components were modeled in CATIA were the basic shapes of the components

sketched and extruded. The bulk densities of the components were calculated to give them the

correct mass in CATIA. The components were assembled in an assembly and the dimensions of

the main body were provided by Structures. Each component was loaded into an assembly file

and placed in relation to each other. Initially, making these components fit in the spacecraft was

not an issue; although the wedge shape made it impossible to put any of the components in the

nose section since it due to the small size.

11. 3 Iterations

The changes made through the iterations are given in Table 11.1. The mass angle, length,

width and x cg location changed as the spacecraft evolved. Iteration 0 consisted of a 20 degree

wedge with a length of 2.413m, a width of 1.64m, and a mass of 357 kg. This iteration was run

and cg location was obtained from Aerodynamics. Figure 11.3 shows the movement of the

helium tanks to accomplish a cg movement from at 1.3m to 1.335 as given by aerodynamics.

Figure 11.3

200

Figure 11.4 and Figure 11.5 shows the component locations in the 20 degree wedge.

Figure 11.4

Figure 11.5

201

The 20 degree wedge was the only wedge angle that allowed the fuel tanks to be placed

on top of each other. The fuel tank location was poor since it was behind the cg, but this was

thought to be acceptable since the original cg location estimates for Earth were forward of the cg

locations needed for Venus and Mars. However, this did not remain true for future iterations.

After iteration 0, the wedge degree was reduced to 5 degrees, for iteration 1. The size of the RTG

required that the length of the spacecraft be increased to 5.852m in order to fit the RTG. After

iteration 1 this size was determined to be too large.

Figure 11.6

Figure 11.6 shows the dimensions for iteration 1. The engines are still stacked on top of

each other, the rear extension is .3 m, and the flap remained .25m. The rear extension was need

during all iterations since the engines were not shielded from the flow by the flap alone.

202

Figure 11.7

Figure 11.7 shows approximant component locations for iteration 1. The helium tanks

remained on the side and the RTG was pushed back to almost the rear wall, while all the

instruments are forward of the bulkhead. After discussion, the instrumentation insulation box

was felt to be unnecessary since the internal vehicle temp was within the instrument operation

range. The tanks were behind the cg and this was a problem that would continue to the end of the

design.

For iteration 2 the length was therefore shrunk to 4.232m, to accomplish this the angle

had to be increased to 8 degrees. This new vehicle was run thru the analyses programs and

determined to still be too large.

Figure 11.8

203

Figure 11.8 shows the dimension of the spacecraft for iteration 2. The engines were

stacked on top of each other. Back extension was .3m and the flap was .25 meters.

Figure 11.9

Figure 11.9 shows the approximate locations for the internal components. The helium

tanks were positioned to obtain the cg location of 1.906m from the front of the spacecraft. The

instruments were still forward of the bulkhead.

The RTG size dictated the length and size of the vehicle until iteration 3 when the

spacecraft was shrunk. This size reduction of the RTG caused several problems with the

locations of the components that became larger then the RTG. With the new smaller RTG the

wedge angle could be retuned to 5 degrees and a shorter length of 3.543m could be

accomplished. The width was also reduced to 1.233m. The smaller wedge angle was necessary to

fly at a lower angle of attack. A 5 degree wedge angle may be unrealistic for the spacecraft of

this length. An 8 or 10 degree minimum wedge angle may have been more realistic but the

smaller angle of attack seemed to be necessary to meet the trajectory conditions.

204

Figure 11.10

Figure 11.10 shows the lengths of iteration 3. The engines were placed side by side

because of the low height in the back. Since the relative size of the engine compared to the

spacecraft was now larger the back extension had to be extended to .55 m to protect them, the

flap length remained .25m. The placement of the engines is poor, since they will impose a

moment when fired due to their location above the cg. Canting them may solve this problem and

should be looked at for the future designs.

Figure 11.11

Figure 11.11 shows the internal components for iteration 3. The location of the engines

was determined solely their size. The fuel tanks radius was reduced so that they would fit in the

205

shorter vehicle. The helium tank changed to be cylindrical since circular tanks could no longer

fit. The RTG stayed at the back of the spacecraft, since its smaller size allowed it to fit in the

smaller vehicle. The RTG in iteration 3, was a problem since it was almost touching the avionics

and scoops. This was done to accomplish the smaller size, despite the problems associated with

this choice, such as overheating the equipment.

Iteration 4 the main engines were changed using new data from propulsion. The mass

was reduced as the length of the Spear was reduced to 3.292m the width was still 1.233m.

Figure 11.12

Figure 11.12 shows the side view and vehicle dimensions.

Figure 11.13

206

Figure 13 shows the top view of iteration 4 where, the back extension was reduced to .3m

and the flap remained .25m.

The new measurements for iteration 5 were a length of 3.974m and the mass was 286 kg.

The wedge angle was 4 degrees.

Figure 11.14

Figure 11.14 shows the internal components for iteration 5. The tanks have changed to

represent the new mass; the helium tank volume was also reduced to better represent the amount

of helium that was needed.

Iteration 6 was to be the last iteration so the mass needed to be increased, to help the

ballistic coefficient for trajectory. A table of mass and cg location for each component is given in

Table 11.2, and a mass breakup given in Figure 11.25. This mass increase was accomplished by

the addition of parachutes. Parachutes were necessary for Earth recovery. The method of

parachute deployment was discussed and determined to be outside the scope of Spear design.

With the parachutes there was no internal space to move components to adjust the cg location.

207

The new cg location provided by aerodynamic were met by adding a drogue chute on the back

extension between the main engines.

Figure 11.16

Figure 11.16 shows the new dimensions of iteration 6, they were length 4.125m width

1.25m, a mass of 399kg and, a 4 degree wedge angle. It was determined that an additional

iteration was necessary due to a final problem with the code not matching.

Figure 11.17

Figure 11.17 shows the top view and component location of iteration 6. The location of the cg

was 1.847 m behind the nose. After a cg range was supplied by aerodynamics, an attempt was

208

made to see if the new cg location due to the absence of fuel would affect the earth entry. The cg

moved to 1.79m behind the front of the nose. This was still in the acceptable cg range.

For iteration 7, the size of Spear would not change but the cg needed to be moved, the cg

location and masses are given in Table 11.3 and mass break down given by Figure 11.26.

Figure 11.19

Figure 11.19 is a view representation of interaction 7. With parachutes taking up all

available room changing the cg location this was accomplished by changing the density of the

UHTC. Although it was not realistic to change materials at this late stage of design, given the

large range of density this change was deemed acceptable as it was necessary to find the cg

location. No information was provided about the nose therefore its size was determined only by

the geometry of the structure and TPS. Since a UHTC geometry , or material had not been

decided, the density was changed to obtain the final stable cg location.

209

Figure 11.20

Figure 11.20 shows the top view of the location of the internal components. The

components and their locations did not change because of the size of the structure stayed the

same.

Figure 11.21

Figure 11.22 shows the side view and the dimensions of the spacecraft. The fuel was

removed to show the cg location for the Earth reentry.

After examining iteration 7 and the fuel and RTG position, several improvements were

made for a starting point of iteration 8. Figure 11.23 shows the dimensions for iteration 8, it was

4.525m long.

210

Figure 11.23

Iteration 8 was not run, but it has several advantages over iteration 7 for systems.

Figure 11.24

Figure 11.24 shows the component locations for iteration 8. The RTG is now separated

from the instruments by the bulkhead. The cg, which would have to changes to be stable, is in

the center of the fuel tanks.

11.4 Conclusion

If more iteration were to be run, attempts could be made to find cg locations for each

planet based on the amount of ablator lost as well as the amount of fuel lost. It was not

attempted; however since the ablator was assumed to ablate all the same so as not to effect the cg

location. Reaction control thrusters would also need to be added to the model and the RTG

would be re-examined and possibly changed again. More scientific components could be added

211

to in order to increase the scientific value of the mission. More communication equipment would

be added in order to facilitate two way communications. These components need to be specified

farther along in the design stage, but were neglected at the design level of the current iteration

due to simplicity.

The wedge shape could also be reexamined and a bifurcated wedge could be used to

allow larger components as well as a lower flight path angle. From a systems point of view, a

small angle is only practical if the length is allowed to increase to contain the necessary systems

which might hamper the cg location. If restrictions are place on the length, the angle should be

increased to allow a larger volume for the components.

Figure 11.25

212

Figure 11.26

Table 11.1

Iteration mass(kg) angle(degree) length(m) width(m) X C.G. (m)0 357 20 2.413 1.64 1.3351 527 5 5.852 1.632 2.9662 536 8 4.232 1.644 1.9063 285 5 3.543 1.233 1.4474 232 5 3.292 1.233 1.6785 286 4 3.974 1.233 1.6566 399 4 4.125 1.25 1.8477 365 4 4.125 1.25 2.022

213

Table 11.2

iteration 6component mass y x zSPEAR 399 0 1.851 0.027RTG 7 0 3.22 0.013MMH 15 0 2.234 0.013NTO 24 0 2.384 0.013MMH tank 1.172 0 2.234 0.013NTO tank 1.172 0 2.384 0.013Engine 6.972 -0.3 3.676 -0.037Engine 6.972 0.3 3.676 -0.037flap 5.753 0 3.759 0.139linear motor(right) 4.376 -0.546 3.107 0.065linear motor(left) 4.376 0.545 3.107 0.065nose 109 0 0.068 0.026insulator body 11.882 0 2.087 0.076helium 0.046 0 2.084 0.013helium tank 1.119 0 2.084 0.013TPS 38.586 0 2.083 0.087Avionics 12.954 0 2.93 0.013gyro 6 0.487 1.88 0.013gyro 6 -0.488 1.88 0.013gyro 6 0 1.88 0.013scoop (left) 7 0.4 3.177 0.013scoop (right) 7 -0.4 3.177 0.013Sample (right) 0.347 -0.301 2.943 0.013Sample (left) 0.347 0.301 2.943 0.013Transponder 0.85 -0.001 1.447 0.013Data thermal 0.6 0 0.704 0.013star tracker 0.3 0 1.628 0.013S-band 0.2 0 0.801 0.013sun sensor 0.1 0.006 1.569 -0.029parachute 24 -0.25 2.62 0.013parachute 24 0.25 2.62 0.013small parachute 19 0 3.409 0.013main body 26.734 0 2.069 0.062

214

Table 11.3Iteration 7component mass y x z

SPEAR 399 0 2.022 0.028RTG 7 0 3.22 0.013MMH 15 0 2.234 0.013NTO 24 0 2.384 0.013

MMH tank 1.172 0 2.234 0.013NTO tank 1.172 0 2.384 0.013

Engine 6.972 -0.3 3.676 -0.037Engine 6.972 0.3 3.676 -0.037

flap 5.753 0 3.759 0.139linear motor(right) 4.376 -0.546 3.107 0.065linear motor(left) 4.376 0.545 3.107 0.065

nose 74 0 -0.032 0.026insulator body 11.882 0 2.087 0.076

helium 0.046 0 2.084 0.013helium tank 1.119 0 2.084 0.013

TPS 38.586 0 2.083 0.087Avionics 12.954 0 2.93 0.013

gyro 6 0.487 1.88 0.013gyro 6 -0.488 1.88 0.013gyro 6 0 1.88 0.013

scoop (left) 7 0.4 3.177 0.013scoop (right) 7 -0.4 3.177 0.013

Sample (right) 0.347 -0.301 2.943 0.013Sample (left) 0.347 0.301 2.943 0.013Transponder 0.85 -0.001 1.447 0.013Data thermal 0.6 0 0.704 0.013star tracker 0.3 0 1.628 0.013

S-band 0.2 0 0.801 0.013sun sensor 0.1 0.006 1.569 -0.029parachute 24 -0.25 2.62 0.013parachute 24 0.25 2.62 0.013

small parachute 19 0 3.409 0.013main body 27.813 0 2.122 0.059top body 18.671 0 1.784 -0.044

215

References

Methods Handout

www.atomicinsights.com (sep96 Cassini)

http://www.aeroastro.com/datasheets.php

X-Band Transponder

MicroCore Avionics Module

Miniature Star Tracker www.aerotech.com

BLMH Series Linear Motors

http://marsrovers.jpl.nasa.gov/mission/spacecraft_edl_parachute.html

AIAA-90-3854

AIAA-89-0097

216

Appendix A - Aeroheating

Mars: Figure 2.1 above and Figure 2.2 below

217

Venus: Figure 2.3 above and Figure 2.4 below

218

Earth: Figure 2.5 above and Figure 2.6 below

219

Mars: Figure 2.7

Venus: Figure 2.8

220

Earth: Figure 2.9

221

Varying flap length

Trial Number10/20/2005 - 22

10/20/2005 - 23

10/20/2005 - 24

10/20/2005 - 25

10/20/2005 - 26

Vehicle Parameters

Angle of Attack 5.00 5.00 5.00 5.00Flight Path Angle -15.5 -15.5 -15.5 -15.5

Length of Plate (m) 2.8 2.8 2.8 2.8Flap Chord (m) 0.275 0.3 0.325 0.35 0.4

Width of Plate (m) 2 2 2 2Radius of Nose (m) 0.002 0.002 0.002 0.002 Cannot

Axial CG Location (m) 1.45 1.45 1.45 1.45 trim withVertical CG Location (m) 0 0 0 0 greater

flaplength

OutputsMax Stag Wall Heat Flux

(J/m^2*s) 16626.6 16626.6 16626.6 16626.6at time (s) 2031 2031 2031 2031 Cannot

Max Stag Wall Temp (K) 278.1683 278.1683 278.1683 278.1683 trim withTime in Atmosphere (s) 1129 1129 1129 1129 greater

Time in Atmosphere (min) 18.82 18.82 18.82 18.82 flapMinimum Altitude (km) 75.775 75.775 75.775 75.775 lengthDepth into Atmosphere 24.225 24.225 24.225 24.225

Changed the flap length from .275 to .4 did not significantly alter the heating but made ituntrimmable when the flap was too large

Figure 2.10

222

500 1000 1500 2000 25000

0.5

1

1.5

2

2.5

3x 10

4 Wall heat flux (dTw /dt) vs Time (s)

Time (s)

Wal

l hea

t flu

x (J

/m2 *s

)

qw stag

q2

q3

q4

q5

q6

q7

q8

q9

q10

Trade Study: Figure 2.11

500 1000 1500 2000 2500 3000

160

180

200

220

240

260

280

300

320Wall Temp (K) vs Time (s)

Time (s)

Wal

l Tem

p (K

)

Tw stag

T2

T3

T4

T5

T6

T7

T8

T9

T10

Trade Studies: Figure 2.12

223

Appendix B - Plots for all Earth Re-Entry Iterations

alpha, deg.

cmcg

10 20 30 40 50 60 70-0.002

-0.001

0

0.001

0.002

Frame 001 03 Dec 2005 AEROPROP, lcg= 2.9660 ycg= 0.01 lplate= 5.56 lflap= 0.25 rnose=0.0050

Figure 20: Stability for Iteration 1

300 350 400 450 500 550 600 650 700 7504

5

6

7

8

9

10

11

12

13

14x 10

4 Altitude vs. Time

Time (seconds)

Alti

tude

(met

ers)


Figure 21: Iteration 1 Flight Path

224

300 350 400 450 500 550 600 650 700 7500

1

2x 10

4 Temperature and Velocity vs. Time

Time (seconds)

Vel

ocity

(met

ers/

seco

nd)

300 350 400 450 500 550 600 650 700 7500

500

1000

Sta

gnat

ion

Poi

nt T

emp

(Kel

vin)

Figure 22: Iteration 1 Heating

300 350 400 450 500 550 600 650 700 750-6

-4

-2

0

2

4Deceleration Force and its Direction

Time (seconds)

Flig

ht P

ath

Ang

le (d

eg)

300 350 400 450 500 550 600 650 700 750-8

-6

-4

-2

0

2

Dec

eler

atio

n Fo

rce

(Gs)

Figure 23: Iteration 1 Loading

225

300 350 400 450 500 550 600 650 700 75020

22

24Angle of Attack and Altitude vs. Time

Time (seconds)

Ang

le o

f Atta

ck (d

eg)

300 350 400 450 500 550 600 650 700 7500

1

2x 10

5

Alti

tude

(met

ers)

Figure 24: Iteration 1 Angle of Attack

300 350 400 450 500 550 600 650 700 7500

1

2x 10

5 Bank Angle and Altitude vs. Time

Time (seconds)

Alti

tude

(met

ers)

300 350 400 450 500 550 600 650 700 7500

100

200

Ban

k A

ngle

(deg

)

Figure 25: Iteration 1 Bank Angle

226

alpha, deg.

cmcg

10 20 30 40 50 60 70-0.02

-0.01

0

0.01

0.02

Frame 001 13 Nov 2005 AEROPROP, lcg= 2.2000 ycg= 0.00 lplate= 3.83 lflap= 0.25 rnose=0.0050


300 350 400 450 500 550 6004

5

6

7

8

9

10

11

12

13

14x 10

4 Altitude vs. Time

Time (seconds)

Alti

tude

(met

ers)



227

300 350 400 450 500 550 6000

5000

10000

15000Temperature and Velocity vs. Time

Time (seconds)

Vel

ocity

(met

ers/

seco

nd)

300 350 400 450 500 550 600200

400

600

800

Sta

gnat

ion

Poi

nt T

emp

(Kel

vin)


300 350 400 450 500 550 600-10

-8

-6

-4

-2


Time (seconds)

Flig

ht P

ath

Ang

le (d

eg)

300 350 400 450 500 550 600-8

-6

-4

-2

0

2

Dec

eler

atio

n Fo

rce

(Gs)


228

300 350 400 450 500 550 60036

36.2

36.4

36.6

36.8

37

37.2

37.4

37.6

37.8


Time (seconds)

Ang

le o

f Atta

ck (d

eg)

300 350 400 450 500 550 6004

5

6

7

8

9

10

11

12

13

14x 10

4

Alti

tude

(met

ers)


300 350 400 450 500 550 6000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2x 10


Time (seconds)

Alti

tude

(met

ers)

300 350 400 450 500 550 6000

20

40

60

80

100

120

140

160

180

200

Ban

k A

ngle

(deg

)


229

alpha, deg.

cmcg

10 20 30 40 50 60-0.02

-0.01

0

0.01

0.02

Frame 001 17 Nov 2005 lcg=2.035 ycg=0.0250 lplate=3.356 lext=0.550 lflap= 0.25 rnose=0.0050 inclang= 5.00

Figure 32: Stability for Iteration 3 (not used)

*Note* Iteration 3 was abandoned, no plots available

alpha, deg.

cmcg

10 20 30 40 50 60-0.02

-0.01

0

0.01

0.02



230

300 400 500 600 700 800 900 1000 11000.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10

5 Altitude vs. Time

Time (seconds)

Alti

tude

(met

ers)



300 400 500 600 700 800 900 1000 11000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2x 10


Time (seconds)

Vel

ocity

(met

ers/

seco

nd)

300 400 500 600 700 800 900 1000 11000

100

200

300

400

500

600

700

800

900

1000

Sta

gnat

ion

Poi

nt T

emp

(Kel

vin)


231

300 400 500 600 700 800 900 1000 1100-6

-5

-4

-3

-2

-1

0

1


Time (seconds)

Flig

ht P

ath

Ang

le (d

eg)

300 400 500 600 700 800 900 1000 1100-3.5

-3

-2.5

-2

-1.5

-1

-0.5

0

0.5

Dec

eler

atio

n Fo

rce

(Gs)


300 400 500 600 700 800 900 1000 110036

36.2

36.4

36.6

36.8

37

37.2

37.4

37.6

37.8


Time (seconds)

Ang

le o

f Atta

ck (d

eg)

300 400 500 600 700 800 900 1000 11000.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10

5

Alti

tude

(met

ers)


232

300 400 500 600 700 800 900 1000 11000.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10


Time (seconds)

Alti

tude

(met

ers)

300 400 500 600 700 800 900 1000 11000

20

40

60

80

100

120

140

160

180

200

Ban

k A

ngle

(deg

)


alpha, deg.

cmcg

10 20 30 40 50 60-0.02

-0.01

0

0.01

0.02



233

300 400 500 600 700 800 900 1000 1100 1200 13003

4

5

6

7

8

9

10

11

12

13x 10

4 Altitude vs. Time

Time (seconds)

Alti

tude

(met

ers)



300 400 500 600 700 800 900 1000 1100 1200 13000

5000

10000

15000Temperature and Velocity vs. Time

Time (seconds)

Vel

ocity

(met

ers/

seco

nd)

300 400 500 600 700 800 900 1000 1100 1200 13000

500

1000

1500

Sta

gnat

ion

Poi

nt T

emp

(Kel

vin)


234

300 400 500 600 700 800 900 1000 1100 1200 1300-20

-15

-10

-5

0

5


Time (seconds)

Flig

ht P

ath

Ang

le (d

eg)

300 400 500 600 700 800 900 1000 1100 1200 1300-4

-3

-2

-1

0

1

2

Dec

eler

atio

n Fo

rce

(Gs)


300 400 500 600 700 800 900 1000 1100 1200 13005

10

15

20

25

30


Time (seconds)

Ang

le o

f Atta

ck (d

eg)

300 400 500 600 700 800 900 1000 1100 1200 13002

4

6

8

10

12

14x 10

4

Alti

tude

(met

ers)


235

300 400 500 600 700 800 900 1000 1100 1200 13000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2x 10


Time (seconds)

Alti

tude

(met

ers)

300 400 500 600 700 800 900 1000 1100 1200 1300-200

-150

-100

-50

0

50

100

150

200

Ban

k A

ngle

(deg

)


alpha, deg.

cmcg

10 20 30 40 50 60-0.02

-0.01

0

0.01

0.02



236

300 400 500 600 700 800 9000.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10

5 Altitude vs. Time

Time (seconds)

Alti

tude

(met

ers)



300 400 500 600 700 800 9000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2x 10


Time (seconds)

Vel

ocity

(met

ers/

seco

nd)

300 400 500 600 700 800 9000

100

200

300

400

500

600

700

800

900

1000

Sta

gnat

ion

Poi

nt T

emp

(Kel

vin)


237

300 400 500 600 700 800 900-10

-5

0


Time (seconds)

Flig

ht P

ath

Ang

le (d

eg)

300 400 500 600 700 800 900-4

-3

-2

-1

0

1

2

Dec

eler

atio

n Fo

rce

(Gs)


300 400 500 600 700 800 90047

47.2

47.4

47.6

47.8

48

48.2

48.4

48.6

48.8


Time (seconds)

Ang

le o

f Atta

ck (d

eg)

300 400 500 600 700 800 9000.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10

5

Alti

tude

(met

ers)


238

300 400 500 600 700 800 9000.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10


Time (seconds)

Alti

tude

(met

ers)

300 400 500 600 700 800 900-200

-150

-100

-50

0

50

100

150

200

Ban

k A

ngle

(deg

)


alpha, deg.

cmcg

10 20 30 40 50 60-0.004

-0.002

0

0.002

0.004

0.006

0.008


Figure 51: Stability for Iteration 7 (Earth Specific)

239

50 100 150 200 250 300 350 400 450 500 5500.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10

5 Altitude vs. Time

Time (seconds)

Alti

tude

(met

ers)



50 100 150 200 250 300 350 400 450 500 5500

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2x 10


Time (seconds)

Vel

ocity

(met

ers/

seco

nd)

50 100 150 200 250 300 350 400 450 500 5500

100

200

300

400

500

600

700

800

900

1000

Sta

gnat

ion

Poi

nt T

emp

(Kel

vin)


240

50 100 150 200 250 300 350 400 450 500 550-7

-6

-5

-4

-3

-2

-1

0


Time (seconds)

Flig

ht P

ath

Ang

le

50 100 150 200 250 300 350 400 450 500 550-3.5

-3

-2.5

-2

-1.5

-1

-0.5

0

0.5

Dec

eler

atio

n Fo

rce

(Gs)


50 100 150 200 250 300 350 400 450 500 55056

56.2

56.4

56.6

56.8

57

57.2

57.4

57.6

57.8


Time (seconds)

Ang

le o

f Atta

ck (d

eg)

50 100 150 200 250 300 350 400 450 500 5500.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10

5

Alti

tude

(met

ers)


241

50 100 150 200 250 300 350 400 450 500 5500.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5x 10


Time (seconds)

Alti

tude

(met

ers)

50 100 150 200 250 300 350 400 450 500 550-200

-150

-100

-50

0

50

100

150

200

Ban

k A

ngle

(deg

)


242

Appendix C – Orbital Mechanics Background

Table C.1: Orbital Elements provided by Dr. Howell, Purdue University (AAE 532)

243

Table C.2: Simulation Parameters - Mars

Mars ConstantsRadius (m) 3397000Gravitational constant (m^3/s^2) 4.282837E+13Angular velocity (rad/s) 7.088218E-05Acceleration at surface (m/s^2) 3.84

Trajectory Information (Provided by Tracy Smith, a graduate student of Dr. Longuski)Inertial velocity at minus ∞ (m/s) x-direction: 7877.223154 y-direction: 1059.25892 z-direction: 237.393748 Inertial velocity at plus ∞ (m/s) x-direction: 2281.674584 y-direction: -3142.862266 z-direction: -4072.837473 Initial radius (m) 3847000Desired radius (m) 3847246.844Initial inertial velocity (m/s) 9246.342009Final inertial velocity (m/s) 7344.211183Initial flight path angle (deg) -25.4329492Final flight path angle (deg) 23.93952178

Trajectory Information (assumed for equatorial motion)Initial latitude (deg) 0Initial longitude (deg) 0Initial heading (deg) 0

Trajectory Information (preprocessed)Change in longitude (deg) 106.2969

244

Table C.3: Simulation Parameters - Venus

Venus ConstantsRadius (m) 6051900Gravitational constant (m^3/s^2) 3.248586E+14Angular velocity (rad/s) -2.9932E-07Acceleration at surface (m/s^2) 8.87

Trajectory Information (Provided by Tracy Smith, a graduate student of Dr. Longuski)Inertial velocity at minus ∞ (m/s) x-direction: -2537.21075 y-direction: 4630.96627 z-direction: -3125.00120 Inertial velocity at plus ∞ (m/s) x-direction: -614.22335 y-direction: 2659.53823 z-direction: 4320.43643 Initial radius (m) 6501800.00Desired radius (m) 6501327.98Initial inertial velocity (m/s) 11.72935885Final inertial velocity (m/s) 11.22699679Initial flight path angle (deg) -15.34397464Final flight path angle (deg) 14.93852584

Trajectory Information (assumed for equatorial motion)Initial latitude (deg) 0Initial longitude (deg) 0Initial heading (deg) 0

Trajectory Information (preprocessed)Change in longitude (deg) 60.6610

245

Relating the Turn Angle to the Change in Longitude

Variable Listing

Symbol Definitione Orbital eccentricityv Orbital velocityr Magnitude of radius vector from focus to vehicleβ Angle between radius vector and velocity vectorγ Flight path angleμ Planetary gravitational constantp Semi-latus rectumh Orbit specific angular momentumθ* True anomalyξ, λ Angles defined in Figure V∞ Hyperbolic excess velocityω Argument of periapsisθ Longitude angle

Fundamentals of Orbital Mechanics

The hyperbolic trajectory near a planet has several unique characteristics. First, any

given hyperbolic trajectory is defined by the interplanetary velocity vectors outside of the sphere

of influence of the planet. Tracy Smith provided the radius, velocity magnitude, and flight path

angle for entry and exit of each planet. Utilizing this information, the eccentricity of the

hyperbolic orbit can be found using Equations (Ref 1-1) and by defining the angle β in Figure

1.1:

246

The point in space in which the hyperbolic trajectory passes closest to the planet is

known as periapsis. An imaginary line, known as the line of apsides, may be drawn from the

center of the planet to the periapsis (see Figure 1.2). A point on the hyperbolic trajectory can be

referenced from the line of apsides using true anomaly (θ*). The true anomaly angle is measured

from the line of apsides to the vehicle’s position . The true anomaly of any point along the orbit

can be found by using Equations (Ref. 1-2), (Ref. 1-3), and (Ref. 1-4), solving for θ*:

The true anomalies for the initial and final conditions given by Tracy Smith are found

with these equations. Taking the limit of Equation as r approaches infinity gives an equation for

θ∞*, the true anomaly when the vehicle is outside the sphere of influence of the planet’s

gravitational field. This is shown as Equation :

247

local horizonFigure 1.1

Figure 1.2 above shows the relationships between all the angles of interest in this

problem. The θ∞* angles have already been explained, and the ξ and λ angles are defined by the

dot product of the V∞+ and V∞

- vectors and may be found in Figure 1.2. Equation shows how to

get ξ:

The angle λ is simply 180- ξ, which can be seen from Figure 1.2. Equation shows the

relationship between the rest of the angles in Figure 1.3:

248

Initial line of apsides

λΔω

final line of apsides

ξ

Figure 1.2

It may be hard to see how this works, but Figure 1.3 below is a manipulation of the

angles in Figure 1.2 to make it easier to see how the angles are related:

Figure 1.3

The angle Δω is the difference in the line of apsides from the initial orbit to the final

orbit. Since θ* is measured from the line of apsides in any given orbit, θi* and θf

*, the initial and

final true anomalies, are measured from two different lines of apsides. In order to find the total

longitudinal turn angle between the initial and final states, the change in the line of apsides, Δω,

must simply be added to the true anomalies at the initial and final states. This is quantified in

equation and further clarified in Figure 1.4:

249

θ*-∞

θ*+∞

Δω

λ

Figure 1.4

In the simulation, the code keeps track of the longitude angle, θ, during flight. The code

does not explicitly output θ*, but instead outputs the longitude θ. The change in θ is equal to the

change in θ*, so it isn’t necessary to know the true anomaly. The angle θ can be initialized at the

beginning to be whatever is convenient. For this mission, θ = 0 is the most convenient initial

longitude angle. Once the desired turn angle from the initial to the final conditions is

determined, the longitude angle θ can be utilized to control the vehicle to the desired exit state.

250

Δω

θi*

θf*

Rf

Ri

References

1-1 Equation derived in AAE532, Purdue University. Solution to derivation listed after

references section.

1-2 Equation 1.5-4 in Bate, Mueller, and White. “Fundamentals of Astrodyanmics.” New

York, Dover Publications 1971.





251

Ref Derivation of Eq. 1.1 taken from AAE532, Purdue University Homework Solutions:

252

Appendix D: Three Venus Control Methods

D.1 “if” Statement Method

The basic idea behind the if statement and PID control methods was that specifying a

certain cruise altitude to reduce drag would be the best choice for reaching the exit conditions.

The if statement structure was pretty simple. Here is an example of what it looked like in the

code:

if current altitude > desired altitude then

90º < bank angle ≤ 180º

else if current altitude < desired altitude then

0º ≤ bank angle < 90º

end

The actual value of the bank angle would then be set by how far off from the desired

altitude the vehicle was. This would require more if statements similar to the following:

if current altitude > desired altitude then

if current altitude > desired altitude + 40 km then

bank angle = 130º

else if current altitude > desired altitude + 30 km then

bank angle = 120º


253

bank angle = 110º


bank angle = 100º

else

bank angle = 90º

end

end

Because the vehicle flying through the atmosphere at such high speeds is a very sensitive

system, such a crude control method wasn’t doing a very good job of stabilizing the flight. In

order to get more resolution, the altitude difference between each if statement was shortened.

Eventually, this leads to a large number of statements and long, complicated-looking code. This

doesn’t even take into account that the angle of attack isn’t being varied at all, which could at

least double the length of the code needed. This brings us to the next control method attempted.

D.2 PID Controller

This controller will attempt to maintain a constant altitude through the flight and eject the

vehicle from the atmosphere after a desired turn angle has been achieved. This angle is

determined uniquely from the initial and final conditions data provided by Tracey Smith as

discussed above. This angle is designated by the longitude angle that is tracked by the code. A

more in-depth discussion on how to utilize this angle is presented in Appendix C.

To begin with, the AOA is held constant and only the bank angle is varied. It was

assumed at the beginning that flying at the AOA that produces the best L/D would be optimal.

254

Now the control of the vehicle is a single parameter problem that can be designed with the PID

controller. The general equation for the PID is as follows in equation .

In the PID controller, u(t) is the control parameter, which in this case is the bank angle of

the vehicle, kp is the proportional gain, kd is the derivative gain, and ki is the integral gain. In

order to maintain a constant altitude, the following variables were used. The error, e(t), was

calculated by finding the percent difference from the actual altitude to the desired altitude. The

time derivative of the error was calculated by taking the sine of the flight path angle. This works

because the velocity vector can be broken into a vertical and horizontal component. The vertical

component can be considered the change in altitude per unit time, which is the same as the

change in the error per unit time. This vertical component was found by simply taking the sine

of the flight path angle and multiplying by the magnitude of the velocity vector. Finally, the

integral of the error is simply the altitude error at each time step summed up. Equations , , and

make all this more clear.

The controller constants then must be set to certain values that force the bank angle in a

logical way. Based on the understanding of the vehicle control discussed above, the controller

was designed in the following way. The baseline bank angle was set at 90 degrees. The bank

255

angle was then either increased or decrease from this base line depending on whether the lift was

needed in the upward or downward vertical directions. The controller now looks like the

modified PID equation .

Bank angle is σ, and e(t) and E(t) have been replaced by err and Esum respectively. The

final change to the PID equation is a numerical trick to keep the vehicle in the equatorial plane.

Since the lift vector has a horizontal component when the bank angle is either 0 or 180, the

vehicle begins to turn north or south, depending on the direction of the lift. To cancel out this

turning motion, the bank angle is multiplied by -1 each time step, thus the vehicle will turn only

slightly back and forth each time step. Physically, this is ridiculous. This is simply a

computational trick to keep our in-plane assumption. It would be impossible to actually flip the

vehicle completely around every second, but in order to keep the assumption of flight in the

equatorial plane only, this, or a similar method, would have to be utilized. The final version of

the controller now looks like equation below. The index ‘j’ is simply the time step index in the

numerical simulation.

In order for this controller to be effective, controller constant values must be chosen so

that the system is stable and so that the overshoot and steady state error are minimized. The

units of the constants must cancel out the units of the error variables such that the units are in

degrees. Since the error variables have been normalized, they are all unit-less. This means that

the controller constants all have units of degrees.

256

The method for finding the values is simple and tedious. First, the constants are set to

zero. A desired altitude is chosen, and the simulation runs to completion. Next, kp is set at some

constant that will make the bank angle 0 degrees at some arbitrary large positive altitude error

and 180 degrees at some arbitrary large negative altitude error. This constant is then varied until

it stabilizes the trajectory about the desired altitude. With proportional control only, the altitude

violently oscillates about the desired altitude, so derivative control should be added. kd is given a

small initial value and is increased slowly with each new simulation until the large oscillations

are damped out. kp and kd are then both varied slightly until the overshoot and the oscillations

are sufficiently eliminated. Integral control is added to get rid of any steady state error in the

system. With only kp and kd, the solution may stabilize quite well, but it might be at the wrong

desired altitude. A small value of ki is then set and slowly increased until the steady state error is

sufficiently eliminated. A value of ki that is too large can destabilize the system, so it is kept

very small. These constants are by no means set in stone once they work for one vehicle

configuration and one desired altitude. Different altitudes, different lift and drag coefficients,

and different vehicle masses will demand that the constants be changed to accommodate these

variations. Because of this, the PID controller must be modified, if even only slightly, for every

iteration to make sure that the trajectory is stable and is sufficiently close to the desired

trajectory.

The basic trajectory flown follows a similar model to that of Professor Longuski’s

students. Referring back to Figure 7.3, the three sections of flight can be described in the

following way. Through section 1 of the flight, the vehicle AOA is set to the lowest possible

value (the included angle of the wedge) to reduce the drag as much as possible. The bank angle

through this section is set at a constant value between 0º and 180º depending on how high or low

257

in the atmosphere the desired cruise (section 2) altitude is. Section 2 of the flight is where the

PID controller is implemented. The AOA is set to a value that is sufficiently able to control the

vehicle at whatever altitude it has reached for the cruise section. The bank angle is then varied

by the controller to maintain that altitude. It turns out in the end that the integral control isn’t

really necessary. It isn’t critical to maintain the cruise altitude exactly. It is only critical that the

vehicle has nearly zero flight path angle for the duration of the controlled path. The small

amount of steady state error that accumulates is insignificant, so it can be ignored. After the

vehicle has flown through the desired turn angle, the PID controller is turned off and the vehicle

AOA is again minimized and the vehicle is allowed to exit the atmosphere (Section 3). The bank

angle is again set at a constant value, which can be adjusted to make corrections to the exit flight

path angle.

The PID control method did have some major problems though. Figure D.1 below shows

a typical bank angle vs. time profile for a controlled altitude. It would be impossible to expect

the vehicle to change its bank angle so sporadically between 0º and 180º as this plot suggests.

The profile didn’t always turn out like this, but there was no way to know if the bank profile

would be a smooth steady line or if it would be like this one from iteration to iteration. The only

way to avoid such wild vehicle motion was to either revamp the PID control scheme or look at a

different method.

258

0 200 400 600 800 1000 1200 1400 1600 1800-0.5

0

0.5

1

1.5

2

2.5

3

3.5Bank Angle vs. Time

Time (s)

Ban

k A

ngle

(rad

)

Figure D.1

D.3 Simplified AOA and Bank Angle Control Scheme

Although the PID controller was a much more sophisticated and powerful method, it

turned out that the trajectory model that matched the exit conditions the best while accumulating

the least amount of drag was a very simple, constant AOA and constant bank angle scheme with

only a few maneuvers. Referring again to Figure 7.3, sections 1 and 3 of the flight are exactly

the same as in the PID control scheme. Instead of using the PID controller during the cruise in

section 2, the vehicle was banked completely at 180º and the angle of attack was set at a

constant. This constant value is found to be the angle of attack that holds the vehicle near zero

flight path angle. Finding this AOA is a tedious process, but not as tedious as adjusting the

controller gains. Basically, if the AOA is slightly larger than what is needed at a particular

altitude, the vehicle will eventually descend into the planet. If the AOA is slightly smaller than

desired, the control of the vehicle is lost and it returns to space much earlier than is desired.

Once an AOA that falls in the controllable range is found, the vehicle is flown until the desired

turn angle is reached and the flight then transitions into section 3. In essence, this method is an

259

even simpler version of the if statement method. The biggest difference is that the code must be

run over and over again until the exact AOA is found. It turns out that this method produces

altitude vs. time plots that are almost identical to the PID controller. The biggest difference is

that the AOA chosen remains very small and the vehicle is not flipped around wildly during the

flight.

260

Appendix E: SODDIT/Matlab interactive code and other SODDIT related Matters

Index

Section 1: SODDIT

1.1 …………………. Input files

1.2 …………………. Block 1

1.3 ………………… Block 5

1.4 …………………. Block 6

1.5 …………………. Block 7

1.6 …………………. Reinitialization

1.7 …………………. Output files

Section 2: MacDermott SODDIT Interaction Files

2.1 …………………. macd_soddit_run.m

2.2 …………………. soddit_control.m

2.3 …………………. macdstuff1.m

2.4 …………………. soddit_between.m

2.5 …………………. mysoddit.m

Section 3: SQP Optimization of Thickness

3.1 …………………. Introduction to SQP

3.2 …………………. aae550proj.m

3.3 …………………. aae550func.m

3.4 …………………. aae550con.m

3.5 …………………. optim_macd_soddit_run.m

261

3.6 …………………. optim_soddit_control.m

Section 1: SODDIT

1.1 Input Files

SODDIT uses input files to read data and set certain conditions. These input files must

be formatted in a certain way. There are 11 blocks for inputs and of these, you will probably use

only the first 7. The SODDIT input files need to be exactly formatted, or SODDIT will not run.

To do this by hand, I suggest using an older file and modifying the parts you need so that they

will do what you want.

1.2 Block 1

Block 1 of the input file has 80 different flags. Each flag turns a portion of SODDIT on

or off. These in turn determine how SODDIT will look at the input file you have inputted

Flag Value What it does

flag 2 0 automatic node generation with same

initial temperature

262

3 specified node generation with

individual thicknesses and temp

flag 4 0 No ablation

3 Ablation

flag 5 0 only _out.txt file given as output

1 adds a _plt.txt file to outputs

flag 16 1 all calculations are assumed to be in SI

.

If you want to know more about the other flags, go ahead and look it up in the soddit manual.

The default value is zero, and I suggest leaving all flags but 2, 4, 5, and 16 as zero and not

messing with them.

1.3 Block 5

Block 5 is the material files. There will be one section for each material used. If you

want two layers made of the same material then there need to be two blocks of the same material.

The outermost material will be the first one listed. The material files must also be formatted

correctly. Once again I suggest that you take an older file, ablating or non, and use that as a

template

For the material files you will need the reference temperature, density, heat of ablation,

and temperature of ablation. Then you will need specific heat, thermal conductivity, emmitance,

263

and absorption values for various temperatures. This is all true of an ablator, for a non-ablator

heat of ablation and temperature of ablation are left as zero.

The file format looks like this:

**rho dhf treff qstar tabl matnam (start past col 41)

4.80e+02 0.0 298. 5.41e+07 588. SLA-561V (ablator)

**temp cp cond emit absrp

2.77778e+02 1.04670e+03 1.19629e-01 .90 1

3.11111e+02 1.17231e+03 1.19629e-01 .90 1

1.94444e+03 1.17231e+03 3.55148e-01 .90 1

-1 5.55556e+03 1.17231e+0 3 3.55148e-01 .90 1

The -1 at the end of the block signals the end of that particular section of the materials file.

1.4 Block 6

Block 6 deals with node generation. This can either be done by soddit when flag 2 = 0 or

it can be done by you with flag 2 = 3.

When you want to do it yourself, you will need to specify an initial temperature for all the nodes

and then the material number, how many nodes for that material, and the thickness of that region.

It will look something like this:

**block 6 automatic node generation data

264

**initial temperature

200

**(mat no) (elements/region) (region thickness)

1 15 0.01000

2 15 0.00318

3 5 0.00800

/end of Block 6 Node generation

If you want to specify the node thickness, temperature, etc… then you need to set flag 2 = 3 and

then set up the initial nodes. To do this you will have to input a node number, the material of

that node, the thickness of that node, the temperature, area, column, and flag. Ignore the area,

column, and flag, and just set up the others as you want.

If you are reinitializing the code then at the very bottom of the _out.txt file you will find a re

initilization block that looks like this:

**(Node) (material node) (thickness) (Temp) (Area) (colume) (flag)

1 1 1.9679E-04 587.00000 1.0000E+00 1.9679E-04 0

2 1 1.9679E-04 575.95920 1.0000E+00 1.9679E-04 0

3 1 1.9679E-04 563.94777 1.0000E+00 1.9679E-04 0

4 1 1.9679E-04 551.97253 1.0000E+00 1.9679E-04 0

5 1 1.9679E-04 540.04000 1.0000E+00 1.9679E-04 0

6 1 1.9679E-04 528.15632 1.0000E+00 1.9679E-04 0

7 1 1.9679E-04 516.32727 1.0000E+00 1.9679E-04 0

8 1 1.9679E-04 504.55824 1.0000E+00 1.9679E-04 0

265

9 1 1.9679E-04 492.85422 1.0000E+00 1.9679E-04 0

10 1 1.9679E-04 481.21977 1.0000E+00 1.9679E-04 0

11 1 1.9679E-04 469.65904 1.0000E+00 1.9679E-04 0

12 1 1.9679E-04 458.17576 1.0000E+00 1.9679E-04 0

13 1 1.9679E-04 446.77325 1.0000E+00 1.9679E-04 0

14 1 1.9679E-04 435.45439 1.0000E+00 1.9679E-04 0

15 1 1.9679E-04 424.22167 1.0000E+00 1.9679E-04 0

16 2 1.3333E-04 413.07719 1.0000E+00 1.3333E-04 0

17 2 1.3333E-04 403.42079 1.0000E+00 1.3333E-04 0

18 2 1.3333E-04 393.73893 1.0000E+00 1.3333E-04 0

19 2 1.3333E-04 384.03103 1.0000E+00 1.3333E-04 0

20 2 1.3333E-04 374.29643 1.0000E+00 1.3333E-04 0

21 2 1.3333E-04 364.53444 1.0000E+00 1.3333E-04 0

22 2 1.3333E-04 354.74431 1.0000E+00 1.3333E-04 0

23 2 1.3333E-04 344.92527 1.0000E+00 1.3333E-04 0

24 2 1.3333E-04 335.07649 1.0000E+00 1.3333E-04 0

25 2 1.3333E-04 325.19709 1.0000E+00 1.3333E-04 0

26 2 1.3333E-04 315.28617 1.0000E+00 1.3333E-04 0

27 2 1.3333E-04 305.34275 1.0000E+00 1.3333E-04 0

28 2 1.3333E-04 295.36583 1.0000E+00 1.3333E-04 0

29 2 1.3333E-04 285.35435 1.0000E+00 1.3333E-04 0

30 2 1.3333E-04 275.30723 1.0000E+00 1.3333E-04 0

31 3 1.6000E-03 265.22330 1.0000E+00 1.6000E-03 0

32 3 1.6000E-03 261.72848 1.0000E+00 1.6000E-03 0

33 3 1.6000E-03 258.97647 1.0000E+00 1.6000E-03 0

34 3 1.6000E-03 256.99223 1.0000E+00 1.6000E-03 0

35 3 1.6000E-03 255.79416 1.0000E+00 1.6000E-03 0

0 0 0.0000E+00 255.39353 0.0000E+00 0.0000E+00 0

266

In this format all you gotta do is copy and paste this into the new input file and it will have

everything it needs.

1.5 Block 7

This is where the heat flux goes. Your areoheating/trajectory people should be able to get you a

heat flux file. Ask for it in Watts per meter squared. It will look like this:

**block 7 front face boundary condition data

**ibcty1 ifmt1 trad1

1 0 20.

**time rec enthapy rad input C sub h P

** sec J/Kg W/m^2 Kg/m^2-s atm

0 0 6.07E+04 0

1 0 5.79E+04 0

2 0 5.52E+04 0

3 0 5.27E+04 0

4 0 5.02E+04 0

5 0 4.79E+04 0

6 0 4.63E+04 0

7 0 4.43E+04 0

8 0 4.21E+04 0

9 0 4.01E+04 0

10 0 3.81E+04 0

11 0 3.62E+04 0

12 0 3.45E+04 0

13 0 3.28E+04 0

267

14 0 3.12E+04 0

15 0 2.97E+04 0

Ibcty1, ifmt1, and trad1 are all explained in the SODDIT booklet.

1.6 Reinitialization

Because of the way SODDIT was created, it has a bug where if the temperature of the

outermost node drops below the ablation temperature then the code starts spitting out corrupted

data. To fix this, you go back and run the code to the time step before it crapped out and drop

the outer temperature by 1 degree. You use flag 2 = 3 and copy and past the block 6 information

as shown above from the _out.txt file. At this point you make block 7 input start at the time step

after the one you started at and presto, more soddit data you couldn’t get before.

1.7 Output files

There are two main output files that soddit will output.

1.7.1 _out.txt files

Every time you run SODDIT you will get a *_out.txt file. The * will be whatever the name of

the input file was. This file will contain all the data you could possibly need to find from

SODDIT. It gives temperature at node, heat data, ablation, and other quantities all at time. The

268

most important part of this is the very last block of data. This block is used for the

reinitialization.

1.7.2 _plt.txt files

The *_plt.txt is an optional file. You get this by activating flag 5. IT contains most of the data

from the *_out.txt file, but in a more user friendly format. It is meant to be plotted, hence the

name. I found the _plt.txt files to be the most useful when looking at data.

Section 2: MacDermott SODDIT Interaction Files

2.1 macd_soddit_run.m

The main control file for my SODDIT code is macd_soddit_run.m. I have coded just

about everything you could want to change into this one file. There are thee main sections.

2.1.1 Heating Files

The heating files control is how SODDIT interacts with the rest of the mission. It is the

only place that data from other sections of the mission can affect the TPS.

heatfilename is a string. It names the heating file that is to be used. This will be passed

into soddit_control later.

269

Name is a variable that has the heating file loaded into it. This allows you to find the

max time that the heat file runs. This is important because SODDIT will continue to run till it

encounters an error or until I hits the max time. So even if there is no heating data it will

continue to run. m is the max time contained in the heating file.

Tmax is the maximum time you want to code to run. If you don’t care if SODDIT runs

quickly or not, set it to m, if you want fast runs, then find the time till ablation stops, and then set

it equal to one time step before the ablation stops.

heatingpoint can be a scalar or a vector. It is the heating point that soddit will look at for

that run. Each heating point (if there are more than one) will have its own data and plot.

heatingpoint = 1 should be the stagnation point and 2, 3, 4,… will be the next point down on the

craft.

2.1.2 Materials section

The material section contains all the information SODDIT needs to determine what is

going on in a regular (not reinitialization) run.

number_of_materials in theory determines the number of materials. In practice, because of the

way I coded it, must remain at 3 or less. This was a slight oversight, but I don’t think you will

need more than 3 materials. I didn’t.

270

matname# is a string. This string names the materials that will be used for that layer.

matthick(#) is a scalar that is the thickness, in meters, of that layer of material

matnodes(#) is the integer value of the number of nodes you want the material to have. The

more nodes, the more data point there will be in the material. I suggest 15, unless the layer is

very thin.

ablate(#) is a flag that tells SODDIT if that layer is going to ablate. ONLY THE TOPMOST

LAYER CAN HAVE A FLAG = 1 all other layers must be zero. Having ablate(#) = 1 turns on

ablation for that layer. Having ablate(#) = 0 turn off ablation for that layer.

multi(#) is useless. It was originally meant to allow for the thickness of a layer to change in the

heckler code. I do not use it at all. Setting it to 1 turned on the varying thickness, setting it equal

to 0 turned it off. If sweep (talked about later) is zero it doesn’t matter. I suggest not messing

with it. The only reason it is still here is that it is hard coded into the heckler code and was easier

to ignore than to remove.

2.1.3 Other Stuff

This is the stuff that doesn’t really fit a category, but is important anyways.

271

sweep was originally, in the heckler code, meant to be a vector full of number to mulitpy the

thickness by and try to find an optinal solution. For my code, it needs to be zero, because I only

want to look at a single thickness at a time.

Run is slightly redundant. In theory if you want to run a non-ablating case, just make all

ablate(#) = 0 and it will do it. However, if you want to, you can also change it down here by

setting run = 1, if run is anything else, then it is an ablation case.

Soddit_control has been turned into an function here, and it called.

2.2 soddit_control.m

This was the main script for the heckler code. I turned it into a function that I could call.

The first for loop assigns the material properties to names that the file likes.

Then the Twall is set. This is ONLY used for the plotting that comes later in the second for

loop.

Sweep, useless, but hard coded into the other functions and therefore a pain. Igmore it here.

The decond for loop runs the SODDIT code. DO NOT JACK WITH ANY OF THIS STUFF. It

will only mess you up. lcv is what this section calls the variable heatingpoint. Macd_stuff1.m is

the only change I made to this section

272

Down at the very bottom it saves a number of variable, some of them are used elsewhere, others

are not.

2.3 macdstuff1.m

This file is my own creation. It allows for a visual representation of what is goug on. It

is a function and it runs inside the 2nd for loop of soddit_control.m. What it does is load a file

called Lastrun.mat that the heckler code spits out and then finds the layer thicknesses, and

temperature between layers and then plots them. It does both plots on the same figure using

subplot and then names them for you. Very nice file.

2.4 soddit_between.m

This is a major portion of the heckler code. There is NO reason to mess with this one. It

does nothing but call the function mysoddit as many times as is necessary.

2.5 mysoddit.m

This is a very, very important file. It builds the input file for you and then runs SODDIT.

It is very important that you change at least the next four variables.

273

Make sure that soddit_exe is a string that contains the correct location information.

Without this the code WILL NOT RUN

Also make sure that soddit_path is a string that is the right location. Without this the

code WILL NOT RUN.

current_directory is a string that is the location and path where all you files are saved. If

this is not correct matlab wont be able to find itself to run these files

materials_directory is the string for th path where all the material files are saved. Make

sure this is correct as well.

The rest of the file sets up the input file. These are subdivided into blocks. If you need to

look at one of the blocks, it should be easy enough to find. It also reads the _plt.txt file and gets

data to use.

Section 3: SQP Optimization of Thickness

3.1 Introduction to SQP

Sequential Quadratic Programming is an optimization method that finds a better solution

for a given function by approximating that function. The approximation is a quadratic

274

approximation of the original function. This approximation is then minimized and the minimal

solution is used as the starting point for the next step.

What I have done, is suing Matlab’s fmincon function, set up a system of scripts and

functions that will do an SQP minimization of the thicknesses of the ablator and the insulator.

The objective function is the summation of the density times the thickness for each layer.

The names reflect that I also used this as an assigmne for AAE 550, Multidisciplinary

Design Optimization.

3.2 aae550proj.m

The first thing this does is set up a global variable. This variable will be read both here and in

optim_macd_soddit_run.m. It sets the heating file that is to be used.

Tmax is just the max time you want it to run. I suggest doing a run in

macd_soddit_control.m first to find the time till ablation stops and then using that time.

Point is just the heating point you will be looking at.

The next few lines set up the constraints. There are no linear constraints or equalities or

that is why they are all empty vectors. The lower bounds are set to zero because you can’t have

a negative thickness, and there are no upper bounds.

275

The options are also important. You can learn more about them by using the help

command in matlab. Help optimset

The initial thicknesses are done in CENTIMETERS not meters. Take note of this. This

was done because if you deal with meters then the tolerances go to small to fast.

3.3 aae550func.m

This one is really easy. It is just the objective function. Plain and simple

3.4 aae550con.m

This functions ets up the constraints for the optimization. First it runs

optim_macd_soddit_run.m and then it takes the outputs of this (max time and inner wll temp)

and makes constraints out of them. The first constraint, g(1) is that the inner wall temperature

must be less than or equal to 350 Kelvin. The second constraint, h(1) is that you want the

Maximum time for the run to equal the Maximum time you inputted. This constraint tells you

that there is still TPS, because if all the ablator ablates, then the run terminates prematurely.

3.5 optim_macd_soddit_run.m

276

The first thing that this function does is turn the thicknesses from cm to m. Then it runs

basically the same as macd_soddit_run.m. You can change the materials, etc….

3.6 optim_soddit_control.m

Exactly the same as soddit_control.m except that the plotting function has been removed.

277

cromagnam - purdue engineering · web viewthe stable c.g. location is currently performed manually...

Documents