Patched Conic Interplanetary Trajectory Design Tool

Transcription

1 Copyright by Martin James Brennan 2011

2 The Thesis committee for Martin James Brennan Certifies that this is the approved version of the following thesis: Patched Conic Interplanetary Trajectory Design Tool APPROVED BY SUPERVISING COMMITTEE: Wallace Fowler, Supervisor Cesar Ocampo

3 Patched Conic Interplanetary Trajectory Design Tool by Martin James Brennan, B.S.; B.S. THESIS Presented to the Faculty of the Graduate School of The University of Texas at Austin in Partial Fulfillment of the Requirements for the Degree of MASTER OF SCIENCE IN ENGINEERING THE UNIVERSITY OF TEXAS AT AUSTIN December 2011

4 To Holly for your encouragement, commitment, and love.

5 Acknowledgments This thesis and my educational career was made possible with the support of the important people in my life. My parents and family, who continue to push me to do my best and pursue my dreams. Scott Hawkins for inspiring my passion for science and physics. Dr. Carrie Olsen, who set my foundation in Orbital Mechanics and the nature of gravity. Her example and advice gave me the courage to pursue my graduate studies. Dr. Cesar Ocampo for empowering me with the tools and drive to research spacecraft trajectories. His passion showed me the beauty of orbital science. Dr. Wallace Fowler for his endless insight and cheer. His dedication to students and education is an inspiration. v

6 Patched Conic Interplanetary Trajectory Design Tool Martin James Brennan, M.S.E. The University of Texas at Austin, 2011 Supervisor: Wallace Fowler One of the most important aspects of preliminary interplanetary mission planning entails designing a trajectory that delivers a spacecraft to the required destinations and accomplishes all the objectives. The design tool described in this thesis allows an investigator to explore various interplanetary trajectories quickly and easily. The design tool employs the patched conic method to determine heliocentric and planetocentric trajectory information. An existing Lambert Targeting routine and other common algorithms are utilized in conjunction with the design tool s specialized code to formulate an entire trajectory from Earth departure to arrival at the destination. The tool includes many options for the investigator to accurately configure the desired trajectory, including planetary gravity assists, deep space maneuvers, and various departure and arrival conditions. The trajectory design tool is coded in MATLAB, which provides access to three dimensional plotting options and user adaptability. The design tool also incorporates powerful MATLAB optimization functions that adjust trajectory characteristics to find a configuration that yields the minimum spacecraft propellant in the form of V. vi

7 Table of Contents Acknowledgments Abstract List of Tables List of Figures v vi ix x Chapter 1. Introduction 1 Chapter 2. Current Preliminary Trajectory Design Process Two-Body Motion Basic Patched Conics Initial Assumptions Trajectory Methodology Limitations Lambert Targeting Chapter 3. The Trajectory Design Tool Trajectory Design Tool Summary Trajectory Design Tool Structure Overview MATLAB Driver Interface Trajectory Configuration Function Modules Optimization Function Trajectory Formulation Assumptions Heliocentric Trajectory Legs Planetary Locations vii

8 User-defined Body or Heliocentric Orbit Locations Departure Options Depart Parking Orbit Analytically Depart Parking Orbit (fixed i) Launch Vehicle Departure Arrival Arrival at Parking Orbit Analytically Arrival at Parking Orbit (fixed i) Arrival onto Entry Trajectory Gravity Assists Powered Gravity Assist Unpowered Gravity Assist Deep Space Maneuvers Chapter 4. Results and Performance Voyager 2 Trajectory Comparison Cassini Trajectory Comparison Ulysses Trajectory Comparison Chapter 5. Conclusion Conclusions Limitations Future Work Appendix 122 Bibliography 136 Vita 140 viii

9 List of Tables Characteristics of Keplerian Orbits [2] Relationships of planets sphere of influence with distances from Sun and planets Voyager 2 actual mission data[18] Comparison of Voyager 2 trajectory parameter results Comparison of Voyager 2 trajectory V results Cassini actual mission data [20, 22] Comparison of Cassini trajectory time-line results (actual DSM location as initial guess) [23, 22] Comparison of Cassini trajectory event location results (actual DSM location as initial guess) [22] Comparison of Cassini trajectory V maneuver results (actual DSM location as initial guess) [22] Comparison of Cassini trajectory event location results (initial DSM location determined from Design tool) [23, 22] Comparison of Cassini trajectory event location results (initial DSM location determined from Design tool) [22] Comparison of Cassini trajectory V maneuver results (initial DSM location determined from Design tool) [22] Ulysses mission event data [26] Comparison of Ulysses trajectory data [26, 27] ix

10 List of Figures Conic sections of varying eccentricity [Source: Curtis[3] ] Elliptical orbit Hyperbolic orbit Patched conic trajectory from inner to outer planet (not to scale) Hohmann transfer from inner planet 1 to outer planet 2 [Source: Curtis [3]] Spacecraft departure from parking orbit about Planet 1 [Source: Curtis [3]] Spacecraft arrival at parking orbit about Planet 2 [Source: Curtis [3]] Transfer types for Lambert s problem [Source: Vallado [2]] Varying time of flight for Lambert trajectory [Source: Vallado [2]] Trajectory configuration sequence Trajectory design tool flowchart Trajectory Optimization Flowchart Potential hyperbolic trajectories to match V asymptote [Source: Curtis [3]] Potential launch vehicle trajectories from launch site [Source: Curtis [3]] Increasing velocity gravity assist on trailing side of planet Decreasing velocity gravity assist on leading side of planet Special case gravity assist of V sc < V P with leading and trailing configuration Special case gravity assist of V sc > V P with leading and trailing configuration Varying periapsis radius changes the gravitational bend angle of the gravity assist [Source: Curtis [3]] Arriving and departing hyperbolic trajectories of a powered gravity assist Complete powered gravity assist trajectory x

11 3.3.10Powered gravity assist with Φ r Φ g and V + V (left) or V + < V (right) Powered gravity assist with Φ r < Φ g and V + V (left) or V + < V (right) Voyager 2 comparison of baseline (red) and optimized (black) trajectory Voyager 2 comparison close up view of Earth to Saturn trajectories Voyager 2 departure trajectory from Earth Voyager 2 arrival trajectory at Neptune Voyager 2 unpowered gravity assist trajectory about Jupiter Voyager 2 unpowered gravity assist trajectory about Saturn Voyager 2 unpowered gravity assist trajectory about Uranus Cassini interplanetary trajectory Cassini VEEGA trajectory Cassini first unpowered gravity assist about Venus Cassini second unpowered gravity assist about Venus Cassini unpowered gravity assist about Earth Cassini unpowered gravity assist about Jupiter Cassini arrival to parking orbit about Saturn Ulysses heliocentric trajectory in X-Y-Plane view Ulysses heliocentric trajectory in three dimensional view Ulysses Earth departure trajectory Ulysses Jupiter gravity assist trajectory Ulysses Jupiter gravity assist trajectory (close up view) xi

12 Chapter 1 Introduction Modern spacecraft continue to explore the nature of the solar system and return priceless data from exotic satellites of gas giants, drifting asteroids, and other untapped sources of knowledge to the Universe. Scientists endeavor to investigate as much about an interplanetary celestial body as possible with a single spacecraft, but the limitations on mass restrict the number of instruments that can be carried across the solar system. Though launch vehicles are ever improving, the most efficient method of sending more useful mass outside the influence of Earth s gravity is to reduce the unnecessary mass on board the spacecraft. Most interplanetary missions require a large capacity of fuel for the spacecraft to achieve proper heliocentric trajectories and arrive at the destination celestial body. Utilizing efficient trajectory designs, the amount of propellant required to complete the mission objectives can be significantly reduced, allocating more mass for scientific instruments. Designing a preliminary trajectory is an important step in the mission design process, because of the impact it plays upon the useful spacecraft mass. The mission requirements and objectives help to identify key trajectory features that must be implemented, including launch trajectory constraints, entry or parking orbits about other celestial bodies, etc. These important features and constraints are combined with efficient trajectory configurations, such as deep space maneuvers and planetary 1

13 gravity assists, to create an initial interplanetary trajectory configuration. Once an initial configuration is chosen, the trajectory information can be used in an array of available computer programs to generate more accurate solutions. The accuracy of a trajectory design is determined by comparing the assumptions and forces accounted for in the design to the true trajectory. The more realistic and complex force environments used in the design tool reflect a more accurate trajectory design. The choice of design tool is dependent on the maturity and complexity of the trajectory design as well as the accuracy desired. The current available trajectory design programs require substantial time for learning how to use the tool correctly, usually scaling with how much accuracy and capability is needed in designing the trajectory. Some design tools may be tailored for preliminary trajectory design but either do not provide enough visual outputs to aid in the design process or have a steep learning curve for using the program. Mission Analysis Environment (MAnE) is an example of a preliminary trajectory design tool that delivers helpful information but has limited visual outputs and is not as adaptable as open source code. Some tools that determine a realistic trajectory require more information about the trajectory than available in the preliminary phase. An example of this program is Copernicus. Copernicus is a high accuracy trajectory optimization tool that accounts for many realistic force environments, but it is only able to confidently find an efficient trajectory if the initial guess parameters are close to the solution. The initial guess parameters that it requires for each event are precise Julian dates, location and velocity vectors in the heliocentric and plantar frames, V vectors, and other specialized optimization parameter values. Though these inputs are usually not available in preliminary mission planning, they 2

14 are outputs from the Trajectory Design Tool presented in this thesis. The trajectory design tool developed in this thesis replaces the manual patched conic method and other less useful design tools for preliminary trajectories, giving the designer a powerful tool to quickly and easily explore various trajectory configurations with many helpful visual outputs. 3

15 Chapter 2 Current Preliminary Trajectory Design Process The current trajectory design process for an interplanetary mission begins by defining the design space (the total set of variables and boundary conditions) and outlining a method of exploring that space. Mission parameters and constraints help to identify requirements for the trajectory design space. There are many tools available that may be used to design and explore within these boundaries, though most are not suited for the preliminary trajectory design phase. Trajectory designers typically employ the patched conic method manually to provide initial trajectory information. The manual process is used to investigate by trial and error what trajectory configuration would best accomplish the mission goals. This chapter describes the manual patched conic process to set a foundation for the more powerful trajectory design tool discussed in the next chapter. 2.1 Two-Body Motion An environment with only two gravitating bodies is assumed, a small secondary body such as a spacecraft and a much larger primary body, a planet. A spacecraft traveling in a spherically symmetric celestial body s gravitational field will trace out a conic section path about the primary body centered at the focus. The conic shape, such as a circle, ellipse, parabola, or hyperbola, is identified by 4

16 Figure 2.1.1: Conic sections of varying eccentricity [Source: Curtis[3] ] the eccentricity of the orbit, as defined in Table and illustrated in Figure The specific energy, energy per unit mass, of the orbit increases with each conic type. The most common orbits used in interplanetary trajectory design are elliptical and hyperbolic, which will be the focus of the following orbital mechanics. Spacecraft in conic orbits about a celestial body are described analytically in the two-body problem, where elliptic and hyperbolic orbital locations are solved as a scalar radius. The semimajor axis and eccentricity are used with the true anomaly of the orbit to define the radius of the specific location in the orbit, Equation r = a(1 e2 ) 1 + ecos(ν). (2.1.1) 5

17 Table 2.1.1: Characteristics of Keplerian Orbits [2] Quantity Circle Ellipse Parabola Hyperbola Semimajor Axis, a a = r r p a r a a = a < 0 Eccentricity, e e = 0 0 < e < 1 e = 1 e > 1 Semiparameter, p p = r r p < p < 2r p p = 2r p p > 2r p Period, P P = 2π µ/a 3 P = 2π µ/a 3 P = P = Specific Energy, e e = µ/2a < 0 e = µ/2a < 0 e=0 e = µ/2a > 0 Figure 2.1.2: Elliptical orbit In most trajectory designs, elliptical orbits account for a majority of the interplanetary flight, including parking orbits about planets and most segments of the heliocentric trajectory. The geometry and parameters that will be used to define an elliptic orbit are outlined in Figure The total energy of an orbit is conserved, equaling the sum of the potential and kinetic energy of the spacecraft at any point in the orbit, where V and µ are the velocity at the point r and gravitational parameter of the primary body, respectively [2]. 6

18 E = V µ r (2.1.2) When combined with the specific energy, Equation leads to the vis-viva equation for the spacecraft s velocity, V [5]. V = ± µ ( 2 r 1 ) a (2.1.3) Specific points of interest for an elliptical orbit are the periapsis and apoapsis. The periapsis is the location in the orbit for the closest approach and highest velocity with respect to the gravitational body. Conversely, the apoapsis is the location in the orbit for the farthest point and lowest velocity. An elliptical orbit is considered a closed orbit with negative specific energy, where in a two-body system a spacecraft will remain in orbit about the gravitational body for all time (assuming only spherically symmetric gravitational forces). A hyperbolic orbit is an example of an open orbit with positive specific energy in which a spacecraft is not bound to the celestial body. Hyperbolic orbits are used in trajectory designs to describe a spacecraft s departure, arrival, or flyby of a celestial body, which are only brief periods of time compared to the entire interplanetary trajectory s duration. This high energy orbit is illustrated in Figure with similar defining parameters as an elliptical orbit. All vector parameters are identified throughout the thesis by either bold font or by a vector arrow over the parameter. Because a hyperbolic orbit is an open orbit and continues its flight to an infinite distance from the gravitational body, only a periapsis exists in a two body model with 7

19 V + Δ departure asymptote apse line r ν δ β Φ g p r p a V - Δ arrival asymptote ae Figure 2.1.3: Hyperbolic orbit no unique apoapsis. Although the periapsis is the location of the highest velocity in the hyperbolic orbit, there is no specific point for the lowest velocity. Yet, as an object s distance from the gravitational body grows, the velocity of a hyperbolic orbit slows to a near constant value and direction, which is approximated as, V, the velocity at an infinite distance from the body (also known as hyperbolic excess velocity) [4]. V = µ a (2.1.4) The direction of both approaching and exiting V is depicted in Figure by an asymptote, translated a distance, known as the aiming radius, from a line drawn radially out from the body. 8

20 = µ V 2 (e 2 1) (2.1.5) The turning angle, δ, is a commonly referenced parameter that describes how much an encounter with a celestial body has changed the V direction in planet centered coordinates by comparing the incoming and exiting asymptotes. The location of the periapsis can be defined with respect to either asymptote line in celestial body fixed coordinates by the angle β. The gravitational bend angle, Φ g, is another commonly referenced term to describe the geometry of the hyperbolic orbit, which is equivalent to 2β for a non-thrusting hyperbolic trajectory [3]. δ = 2sin 1 ( 1 e ) (2.1.6) β = cos 1 ( 1 e ) (2.1.7) Φ g = 2β (2.1.8) In the case of an unpowered gravity assist, a non-thrusting planetary flyby, the incoming and exiting V are equal due to the conservation of energy in the celestial body system. V = V + (2.1.9) 9

21 2.2 Basic Patched Conics A true interplanetary trajectory encounters multiple gravitational forces at all times throughout a mission as well as other perturbations, such as solar radiation pressure, atmospheric drag, magnetic forces, etc. This complex set of forces requires numerical integration and detailed knowledge of the mission environment to determine a complete trajectory solution, while the patched conic method utilizes analytical two-body equations to simplify the process and obtain a reasonably good approximation to the desired trajectory. Since a preliminary trajectory design may be required with minimal mission information, the patched conic procedure is preferred for early mission planning. The patched conic approach assumes only the dominant gravitational field acts on the spacecraft at each stage of the flight and all other forces are negligible. The trajectory is divided into heliocentric and planetocentric stages, depending on which body throughout that segment better models the trajectory with two-body motion. The radial distance surrounding a planet where its gravity becomes dominant over the Sun s is defined as the sphere of influence, SOI, of that planet. A common method of defining the SOI of a planet is by comparing the ratio of the perturbing acceleration of the Sun (p s ) and the primary acceleration of the planet (a p ) to the ratio of the perturbing acceleration of the planet (P p ) and the primary acceleration of the Sun (A s ). The ratio p s a p quantifies how much a spacecraft s two-body orbit about a planet is altered by the perturbing third-body force of the Sun, while the ratio P p A s measures the deviation of a spacecraft s two-body orbit about the Sun due to the third-body force of a planet. When the value of P p A s is larger than p s a p, the gravitational influence of the planet is dominant and the vehicle is within the planet s SOI [3]. 10

22 p s = µ s R 3 r p a p = µ p r 2 (2.2.1) P p = a p A s = µ s R 2 p p s a p < P p A s (2.2.2) Expanding Equation in terms of the Sun and planet s mass (m sun and m P ) with the distance between the Sun and planet (R p ) and the distance from the planet to the spacecraft (r), the SOI radius about a planet is reduced to ( ) 2 mp 5 r SOI = R p. (2.2.3) m sun The patched conic method provides a close approximation to the true trajectory, because the SOI of each planet is very small compared to the scale of the heliocentric trajectory, as suggested in Figure 2.2.1, thus spending the majority of the trajectory under the sun s gravitational influence [3]. Consequently, the heliocentric conic legs of the trajectory are determined while treating the planets SOI as mere points in space, having no effect on the heliocentric trajectory. Although, when considering each trajectory in planetocentric coordinates, the SOI is a large enough radial distance from the planet it is considered to be at infinity. Using values from the Explanatory Supplement to the Astronomical Almanac (Seidelmann 1992) 11

23 Heliocentric elliptical transfer trajectory Δ V Planet 2 SOI at arrival Sun Planet 1 SOI at departure Spacecraft parking orbit about Planet 1 β Hyperbolic departure trajectory Planet 1's Sphere of influence Figure 2.2.1: Patched conic trajectory from inner to outer planet (not to scale) 12

24 Table 2.2.1: Relationships of planets sphere of influence with distances from Sun and planets Planet R r planet R planet R SOI R SOI SOI R planet R planet (km) (AU) (AU) R (rsun ) SOI (%) R SOI r planet Mercury Venus Earth Mars Jupiter Saturn Uranus Neptune [7], each planet s SOI and the various relationships as described above are found in Table The radius and average heliocentric orbital distance of each planet (r planet and R planet ) are shown to compare the radius of each planet s SOI (R SOI ) in terms of astronomical units (AU) and in radii of the sun (r sun ). Various ratios are also displayed to compare how R SOI measures up to R planet and r planet. The only exception to this tread is when encountering the largest planet, Jupiter. Its gravitational field has significant influence on a trajectory as a spacecraft approaches the vicinity of the planet. The large distance of gravitational influence alters a trajectory by increasing the spacecraft s velocity toward Jupiter. The increase in heliocentric velocity is not accounted for in patched conics and results in the actual trajectory leg to Jupiter having a shorter time of flight than with the patched conic method. Each individual heliocentric and planetocentric segment of the trajectory is a continuous path, while the entering and exiting locations where the trajectory crosses the SOI of a planet are not necessarily coincident, but have the same velocity 13

25 (when accounting for the change in reference frames). The location discontinuity is where the two trajectories are patched together. In most mission scenarios, the discontinuity is negligible and does not detract from the accuracy of the patched conic approximation, especially when considering that a realistic mission incorporates many trajectory correction maneuvers that would easily compensate for such small errors and produce a continuous trajectory path throughout the mission Initial Assumptions Using the patched conic method for a preliminary trajectory design enables the investigator to further simplify the process with a few key assumptions. One of the most important assumptions is that all V maneuvers are performed impulsively, conforming to the analytical equations used. Most interplanetary missions primarily involve planets, all of which have nearly coplanar orbits, therefore allowing the assumption that the planets orbits and the spacecraft s trajectory will be coplanar. Since most planets orbits have eccentricities close to zero, the planets orbits about the sun are initially assumed to be circular. Though not always possible, using Hohmann trajectories for some, if not all, of the initial iterates of the heliocentric transfers simplifies the computational requirements of the design process significantly. In the initial trajectory design iterates, true planetary positions relative to each other during the mission time-line are freely altered in order to accommodate the Hohmann trajectories and ease of calculation. For further iterates in the process, the true positions and non-zero eccentricities for planetary orbits are used for accuracy and maturing the trajectory design. The trajectory design process must assume that the trajectory encounters the gravitational influence of a planet 14

26 only when directed by the mission plan. Although unlikely, when incorporating true planetary positioning, one might find that the heliocentric trajectory unintentionally intersects the SOI of a planet while on route to another objective. Utilizing the assumptions above gives the design process the ability to quickly generate baseline trajectories and determine the feasibility of the mission Trajectory Methodology The iterative process of interplanetary trajectory design begins by finding a simple baseline trajectory as a reference for comparing future iterations improvements and added complexity. With most missions having a planet as a final destination, the simplest, though not always desirable, trajectory is a Hohmann transfer directly from Earth. This simple case is often used as a baseline trajectory for a mission and is an excellent opportunity to describe each step of determining a preliminary patched conic trajectory, which can easily be extrapolated for complex missions. The heliocentric trajectory segments are determined first, which for a Hohmann transfer, as in Figure 2.2.2, only requires planet 1 s radius at departure (R 1 ), planet 2 s radius at arrival (R 2 ), and the Sun s gravitational parameter, µ sun. V D = V A = ( 2 µ sun 2 ) R 1 R 1 + R 2 ( 2 µ sun 2 ) R 2 R 1 + R 2 The velocities of the planets assumed circular orbits are found with 15

27 Figure 2.2.2: Hohmann transfer from inner planet 1 to outer planet 2 [Source: Curtis [3]] V D : spacecraft departure velocity V 1 : planet 1 orbital velocity V A : spacecraft arrival velocity V 2 : planet 2 orbital velocity 16

28 V 1 = V 2 = µsun R 1 µsun R 2. The heliocentric transfer can now be patched to the planetary reference frames through their respective V, where the velocities are assumed parallel for a scalar calculation. V 1 = V D V 1 V 2 = V A V 2 For a departure from Earth using a launch vehicle, the required V is all that is needed. Yet, if the departure is from a parking orbit, a V is needed to leave the parking orbit with the appropriate periapsis velocity V p1 and achieve the required V 1. V p1 = V µ 1 R park1 The velocity V park1 of the spacecraft in the parking orbit at the moment prior to the V 1 is found if the orbit is assumed circular with radius, R park1 [3]. V park1 = µ1 R park1 V 1 = V p1 V park1 17

29 Figure 2.2.3: Spacecraft departure from parking orbit about Planet 1 [Source: Curtis [3]] 18

30 Most planetary arrivals are in the form of a parking orbit about the arrival planet, leading to similar calculations as performed for the departure case, but typically with specific parking orbital elements. If the mission requires landing on the arrival planet, then the V of the spacecraft at planet 2 is all that would be of interest for preliminary trajectory and mission designers. The parameters that describe the arrival at planet 2 are determined similarly to those from the departure of planet 1. A V is needed to enter the parking orbit with the appropriate periapsis velocity V p2 from the entry hyperbolic trajectory, defined by V 2. The velocity V park2 of the spacecraft in the parking orbit at the moment after the V 2 maneuver is found if the orbit is assumed circular with radius, R park2 [3]. V p2 = V park2 = V µ 2 µ2 R park2 R park2 V 2 = V p2 V park2 The primary goal of the preliminary trajectory design is to generate V and V values for each stage of the mission, which can then be used in the spacecraft design, such as finding the required spacecraft masses with the rocket equation [6], where m 0 is the spacecraft mass before the V propulsion maneuver and m f is the spacecraft mass after the maneuver. Also, g 0 is the acceleration of gravity at earth s surface (used as a scaling factor) and I sp is the specific impulse of the thruster or rocket engine. ( ) m 0 V = exp m f g 0 I sp (2.2.4) 19

31 Figure 2.2.4: Spacecraft arrival at parking orbit about Planet 2 [Source: Curtis [3]] 20

32 2.2.3 Limitations Current preliminary patched conics trajectory design is done by hand or manually iterated with simple computer programming scripts. Since these options are intended to give results in a short time, many approximations and assumptions must be made to simplify the calculation process, as seen in the previous example. Though approximations and assumptions induce some error into the design parameters, such as V and flight duration, the major flaw with this procedure is the limitation it puts on the design process. Missions to outer planets or any celestial bodies beyond Mars require significant V and flight durations when using the direct Hohmann trajectories. Reducing V and sometimes also reducing flight durations, planetary gravity assists and midcourse maneuvers allow missions to the outer solar system to be more feasible. Incorporating a gravity assist or a midcourse maneuver by hand or with a simple computer programming script can be difficult, particularly when considering multiple consecutive maneuvers. Designing a gravity assist requires accurate ephemeris data for each planet involved in the trajectory. It also requires the ability to perform many iterations of the design to find the appropriate timing and positioning of the planets for a useable gravity assist. A midcourse maneuver also requires many iterations to be performed in order to find the time and location of the maneuver that best benefits the trajectory. Most interplanetary trajectories have one or more requirements that disallow the use of Hohmann transfers and therefore require a more complex procedure to find the desired trajectory parameters for mission design. Tools and programming 21

33 scripts to accomplish this task exist but either have limited availability or require knowledge in the programming language or software to be used. 2.3 Lambert Targeting Lambert Targeting is the most common tool used for designing realistic baseline trajectories in mission design. The problem that Lambert Targeting solves is the following: given an initial and final location with respect to a gravitational body and a desired time of flight (TOF) for a spacecraft to complete the orbit segment, find the required velocities at the initial and final positions in a two-body system consisting of the primary gravitational body and the spacecraft. A typical interplanetary mission has initial and final locations at planets and a TOF that creates an elliptical heliocentric trajectory between these planets. Though requiring the user to provide extra information about the mission, the Lambert Targeter can generate a two-body trajectory solution for nearly all relative position configurations and flight times. Designing an interplanetary trajectory with a Lambert Targeting tool better enables the use of gravity assists, midcourse maneuvers, and accurate planetary positions. These capabilities are necessary when exploring various design iterations while seeking an optimal trajectory solution. Lambert s problem has been solved a variety of different ways and has been coded into countless programming languages. The following discussion will focus on the use of a Lambert Targeting program, while the theory and mathematical techniques involved in solving Lambert s problem can be found in other texts. Possibly the most rigorous and descriptive solutions are seen in An Introduction to 22

34 Mathematics and Methods of Astrodynamics, Revised Edition (Battin 1999) [1] or Fundamentals of Astrodynamics and Applications (Vallado 2001) [2]. A typical multiple revolution Lambert Targeting script requires six inputs that describe the conditions of the orbital problem so that the desired outputs can be found. Inputs: 1. µ: gravitational parameter of the central body 2. r 1 : radius vector of initial location with respect to gravitational body 3. r 2 : radius vector of final location with respect to gravitational body 4. TOF: time of flight between initial and final locations 5. d: direction of travel about the central body 6. m: number of orbital revolutions around the central body Outputs: 1. V 1 : velocity vector at initial location 2. V 2 : velocity vector at final location Assuming an interplanetary trajectory, the gravitational parameter is of the Sun. The initial location r 1 is the position vector of the spacecraft about the Sun at the beginning of the orbital transfer, while r 2 is the spacecraft s position vector at the 23

35 Short Way (Δν < 180 ) Long Way (Δν > 180 ) Figure 2.3.1: Transfer types for Lambert s problem [Source: Vallado [2]] end of the orbital transfer. The plane defined by the three points, r 1, r 2, and the origin (Sun) is the orbital transfer plane. The time specified for the spacecraft to travel the orbital segment between r 1 and r 2 is the TOF. The direction of travel is defined in most scripts as either short-way or long-way, which can been seen in Figure to describe the relative angle that the transfer arc sweeps out. A short-way path refers to the direction of flight for the shorter transfer arc that is less than 180 (also known as a type 1 transfer), while the long-way path refers to the longer transfer arc direction that is greater than 180 (also known as a type 2 transfer). Though this method is sufficient for a fixed set of orbital parameters, the spacecraft locations and flight times in an iterative environment can change enough that maintaining a short-way or long-way flight direction is not desirable for all iterations [2]. In most interplanetary missions, the heliocentric angular momentum of each trajectory leg is preserved in the same general direction, prograde or retrograde. 24

36 Figure 2.3.2: Varying time of flight for Lambert trajectory [Source: Vallado [2]] Since all planets (and most minor bodies) orbit the Sun in a prograde direction, with the angular momentum vector pointing in the northern ecliptic hemisphere, most spacecraft trajectories are also in the prograde direction throughout their entire mission. A change in heliocentric angular momentum direction would have the spacecraft reverse its velocity direction, requiring an unrealistic amount of propellant to accomplish such a large V. A Lambert Targeting tool with a direction specified as short-way or long-way may initially produce prograde trajectory segments. Yet, as the iterative design loop continues, the orbital parameters may vary enough to yield a retrograde trajectory segment even though the same short-way or long-way direction has been maintained. Therefore, it is preferred that a Lambert Targeter script be modified to use prograde and retrograde as the choice for direction of travel. The final input of a Lambert Targeting tool is the number of orbital revolu- 25

37 tions the trajectory completes before arriving at the final location. The m parameter is a positive integer value, where zero identifies a trajectory segment that does not travel a full orbital revolution about the central body between initial and final locations. A nonzero value of m refers to the number of circular or elliptical orbits that are completed. A multi-revolution trajectory segment is typically used for synchronization purposes before a maneuver, such as a gravity assist or rendezvous. The outputs of a Lambert Targeting routine are the initial and final velocity vectors, V 1 and V 2, that yield the desired transfer. With the initial and final states (position and velocity vectors) of the spacecraft, the orbital transfer segment is fully defined. The initial state or the final state can easily be converted into orbital elements. The segment information can be used to determine the V required to enter into the transfer from a previous orbit and the V necessary to exit the transfer into the next orbit segment. As with most tools, there are limitations to the use of a Lambert Targeting program. As the r 1 and r 2 vectors of the trajectory segment approach being collinear (angles of 0 or 180 apart), the transfer trajectory tends to become further out of plane compared to the entering and exiting orbital segments. This result is due to the requirement that the transfer plane must contain the initial and final points as well as the central body location. Also, when the position vectors are exactly collinear, most Lambert Targeting scripts cannot yield a solution because an infinite number of transfer planes satisfy the requirements. The collinear condition occurs when a line can be formed through both position vectors and the central body. The 180 collinear case is a Hohmann transfer, and a 0 case is a straight radial transfer with no rotational velocity [2]. 26

38 Chapter 3 The Trajectory Design Tool 3.1 Trajectory Design Tool Summary The purpose of this thesis is to create a trajectory design tool that determines and optimizes interplanetary trajectories using precise planetary ephemerides and accurate patched conic methods. Written in the MATLAB computer programming language and application, the design tool computes the user defined interplanetary trajectory with inputs including various options for departure and arrival, gravity assists, and deep space maneuvers. Each segment of the trajectory is modeled using two body motion, where heliocentric legs are determined by a Lambert Targeting routine and the planetocentric legs are determined by analytical orbital mechanics. The interplanetary trajectory is optimized at all stages of the flight to a prescribed tolerance. The user may direct whether a mission event V maneuver is omitted from the optimization process. The trajectory determination process is formulated so that at each iteration of optimization procedure, the entire trajectory is complete, continuous (with the SOI exception inherent to patched conics), and a realistic candidate for final design selection. After evaluating the trajectory, the user may choose a variety of preconfigured MATLAB visual outputs, trajectory plots or movies with three dimensional vantage point controls. MATLAB provides an adaptable structure for the design tool so that it is easily used by novice trajectory designers while 27

39 Node 3 (Mars) Leg 2 Leg 3 TOF 2 TOF 3 Node 2 (DSM) Sun TOF 1 Leg 1 Node 4 (asteroid) Node 1 (Earth) Figure 3.1.1: Trajectory configuration sequence also providing enough options to model complex trajectories for experienced designers. To better define the design process, a heliocentric trajectory is broken into segments called legs. The initial and ending points of each leg are locations for a potential V maneuver where a mission event would occur. These terminal points of the legs are called nodes and are identified by coinciding with a planet, celestial object, or heliocentric location. Examples of mission events are departing from a planet s parking orbit, performing a gravity assist about a planet, performing a deep space maneuver (DSM), etc. The date when the trajectory begins defines the time leaving the first node, while the TOF for each leg defines all other nodes. 28

40 Input Driver Trajectory Configuration Function Matlab Optimizer Mission Event Modules Trajectory Results User Plotting Outputs Figure 3.2.1: Trajectory design tool flowchart 3.2 Trajectory Design Tool Structure Overview The trajectory design tool is made up of the User Interface Driver (UID), the Central Trajectory Configuration Function, and various modules. The UID is a MATLAB script that provides inputs to the trajectory configuration function, while all other parts of the design tool are written as MATLAB functions which use inputs to perform calculations and deliver outputs as necessary. The trajectory configuration function uses the UID information to direct which modules are called, what optimization scheme is performed, and which visual outputs are generated. The general order of processes performed by the design tool can be seen in Figure After the user has entered all the appropriate information to describe the trajectory, optimization process, and outputs, the UID script is run in MATLAB to begin the computation process. The input information is transferred to the Trajectory Configuration Function, which starts the optimization process and builds the 29

41 trajectory at each iteration by calling the Mission Event Modules. Once the optimization process is complete, the resulting trajectory information is provided to the user and to the plotting functions for output of the desired visual outputs MATLAB Driver Interface The UID is used to communicate the desired trajectory instructions and receive all pertinent outputs from the design tool. Each input parameter entered by the user into the UID script is formatted either as a scalar value, vector, or array. Options regarding the general trajectory design process, such as the type of optimization procedure, are entered as scalar values. Parameters specific to the trajectory configuration are vectors or arrays, where each element in a vector (or row in an array) apply to a corresponding node. The plotting options can be a scalar or a vector, depending on the number of plots desired. The optimization, plotting, and general trajectory configuration parameters are required to be provided by the user, while all others are auxiliary parameters that are only required to be entered if the associated mission event is chosen. Scalar parameters are entered as a simple equivalence statement, for example optimization = 1. A vector parameter is entered as a row vector with appropriate values for each element as they relate to nodes, such as the npl parameter, or trajectory legs, such as the TOF parameter. 30

42 event = [ ] A vector parameter may also be entered by each element individually by specifying the node or trajectory leg index next to the parameter. The flyby radius (in units of the planet s radii) for node two, r f b(2) = An array parameter is entered as a specified row vector of the array according to the proper node or trajectory leg number, such as coep(4,1 : 6) = [ a e i Ω ω ν ], where the classical orbital elements of the vector are already defined above the parameter s location in the script. The following outline defines all the available input options and identifying values, which would potentially be entered into the parameters to fully configure an interplanetary trajectory. Each parameter and function is explained in detail in the following sections. Optimization parameters optimization (scalar) 0: No optimization performed (Fixed parameters) 1: Optimize parameters using MATLAB gradient method with numerical derivatives 31

43 2: Optimize parameters using MATLAB simplex (non-derivative) method optnode (vector): Specifies which nodes are included in the optimization procedure 0: Node (element of vector) not included 1: Node is included optsoi (scalar): Specifies the types of powered gravity assists to be considered in the optimization procedure 0: Near periapsis V only 1: Near periapsis or sphere of influence V optr (scalar): Specifies if the periapsis radius of all gravity assists are varied or fixed in optimization procedure (either all are varied or all are fixed) 0: Periapsis radius is fixed at user-defined value 1: Periapsis radius is varied by optimization process Plotting parameters plotting (vector): Specifies the preconfigured plots to be generated (whether all or just some are plotted) 0: Heliocentric trajectory with planets orbits 1: Heliocentric trajectory with planets orbits and positions at date of first node 9: Heliocentric trajectory movie with planets 10: Departure trajectories at nodes 32

44 20: Arrival trajectories at nodes 30: Flyby trajectories at nodes General trajectory configuration parameters npl (vector): Planets encountered at each node 0: Deep Space Maneuver/ User-Defined Orbit 1: Mercury 2: Venus 3: Earth 4: Mars 5: Jupiter 6: Saturn 7: Uranus 8: Neptune 9: Pluto (dwarf planet) event (vector): Mission event at each node 10: Departure from a parking orbit about planet with i, Ω, and ω as optimization variables 11: Departure from a parking orbit about planet with Ω and ω as optimization variables 14: Departure from a launch vehicle trajectory with Ω and ω as optimization variables 33

45 17: Depart user defined body (with negligible gravity) or heliocentric orbit 20: Arrival to a parking orbit about planet with i, Ω, and ω as optimization variables 21: Arrival to a parking orbit about planet with Ω and ω as optimization variables 24: Arrival to entry trajectory with Ω and ω as optimization variables 27: Rendezvous with user defined body (with negligible gravity) or heliocentric orbit 30: Powered gravity assist 35: Unpowered gravity assist 40: Midcourse maneuver (DSM) with initial location guess provided by program 41: Space burn (DSM) with initial location guess provided by user JD0 (scalar): Initial Julian date (can also provide yr, mon, d, h, min, s for conversion to Julian date) tof (vector): Time of flight in days for each trajectory leg grade (vector): Flight direction of trajectory leg 0: Prograde (similar direction as planets) 1: Retrograde rev (vector): Number of orbital revolutions of trajectory leg 0: Less than a full orbital revolution 34

46 Positive Integer: Multiples of full orbital revolutions Departure/arrival parameters for parking orbits coep (array): Classical orbital elements of parking orbit at particular node [a e i Ω ω ν] Launch/entry parameters altp (vector): Altitude of periapsis (km) for particular node ilv (vector): Inclination of launch or entry trajectory for particular node vinfavmag (vector): Hyperbolic velocity at infinity available from launch vehicle or entry dvopt (vector): Defines if excess V is detrimental ( V ) or acceptable (no V ) 0: Required V =available V 1: Required V available V Gravity assist parameters rfb (vector): Flyby radius magnitude (in radii of particular planet) at node DSM parameters revig (vector): Number of orbital revolutions completed by the leg segments between closest preceding celestial body node and closest celestial body node following 35

47 0: Less than a full orbital revolution Positive Integer: Multiples of full orbital revolutions rnb (array): Space burn heliocentric location in Cartesian coordinates (AU) at particular node User-defined body/heliocentric orbit parameters coenp (array): Classical orbital elements of parking orbit and corresponding Julian date at particular node [a e i Ω ω ν JD] Trajectory Configuration Function The Trajectory Configuration Function is the central programming script that takes the users inputs and manages the trajectory building and optimization process. The main optimization parameters are the TOFs and the Julian date at the first node, which are provided by the user via the UID. The heliocentric location of the DSMs are also optimization parameters if these mission events are chosen. The first module called in the Trajectory Configuration Function is mcmguess (midcourse-maneuver-guess), which checks if any DSMs are needed in the trajectory and if they are midcourse maneuvers or space burns. The midcourse maneuver option uses the locations of the nodes before and after the maneuver to find an average radius and angle between the nodes as a good initial guess for the DSM. The space burn option requires the user to provide a heliocentric location vector as an initial guess for the DSM. The DSM locations will be varied in the optimization procedure. With all optimization parameters determined, the optimization process 36

48 is initialized by formatting the parameters for input into the MATLAB optimization function fminunc. The optimization function uses the total scalar V of the trajectory as its performance index, which is minimized throughout the process. The trajectory information must be computed for the heliocentric legs and the nodes in order to evaluate the V required for each mission event. The Julian dates for the nodes are found from the initial node Julian date and the TOFs. These Julian dates are used by the planet2planet function, which determines the location of the planets from an ephemerides data file (DE405) [25, 24], the location of any user defined bodies, and calls the Lambert Targeter function. The Lambert Targeter function calculates the heliocentric velocity vector of the spacecraft s trajectory at each node. Next, the specific Mission Event Modules must be called to determine the V at each node. A loop iterates through the potential mission event function calls for each node, satisfying a conditional statement to select the desired mission event for that particular node. When the mission event is selected, the module is run and the V for that node is computed. The loop continues for the total number of nodes and sums all the V s with specific nodes omitted as directed by the optnode parameter. One might consider omitting V when the particular node is intended to be any V and not subject to minimization, such as an arrival at a planet where the spacecraft is intended to insert into orbit by aerocapture (without the use of propellant). The performance index with the totaled V for the iteration is analyzed by the optimization function, which determines how the optimization parameters will be adjusted. The initial Julian date, all the TOFs, and any DSM locations 37

49 Start Trajectory Configuration Parameters Midcourse Maneuver Location Initial Guess Optimization Parameter Initialization Depart Parking Orbit (Ω and ω) Depart Parking Orbit (i, Ω, and ω) Depart Launch Trajectory Depart User-Defined Body/Orbit Arrive Parking Orbit (Ω and ω) Arrive Parking Orbit (i, Ω, and ω) Arrive Entry Trajectory Arrive User-Defined Body/Orbit Powered Gravity Assist Unpowered Gravity Assist Midcourse Maneuver Space Burn if if if if if if if if if if if if Loop # Nodes Trajectory Generator Planetary & User-Defined Body/Orbit Ephemeris Matlab Optimizer Performance Function (Σ ΔV) Optimization Routine (Gradient or Simplex) convergence Update Parameters non-convergence Stop Figure 3.2.2: Trajectory Optimization Flowchart are updated, starting the trajectory building process again for the next iteration. The optimization process continues until the function s analysis of the performance index determines that it has converged upon a solution. The a detailed diagram of this process is seen in Figure Modules The Mission Event Modules and other important functions will be focused on in the following discussion. Some modules are not unique to this Design tool and do not require a detailed description. These modules are commonly found algorithms such as converting a spacecraft s location and velocity vector to classical orbital elements. Each module is outlined with a description to follow. The modular design allows the entire design tool program to be more com- 38

50 pact than a large single script. Separate modules isolate problems during development and testing for faster error resolution. With inputs, outputs, and the purpose of the module being explicitly defined, a user is easily able to follow the traceable data paths and better understand the trajectory design concepts. Also, the modules can be used independently of the design tool for other investigations. lambert.m A Lambert Targeter routine already developed by Rody P.S. Oldenhuis[12] was adopted for the design tool. Using an existing Lambert Targeter allows more resources to be focused on the unique programming scripts dedicated to the trajectory design tool. The multiple revolution Lambert Targeter was chosen for its hybrid performance capability of combining a fast convergence algorithm developed by Dr. D. Izzo [13] from the European Space Agency and a robust algorithm by Lancaster and Blancard[14] with modifications by R. Gooding [15]. The routine uses the heliocentric node location vectors, TOF, number of revolutions, and flight direction inputs to compute the velocity vectors required at the node locations to complete the desired trajectory. The original flight direction input of short-way or long-way was modified to instead use prograde or retrograde commands. The prograde direction is defined as the angular momentum vector in the positive z-axis general direction in the heliocentric ecliptic coordinates, with exceptions for special cases. In the event that the angular momentum vector is in the x-y plane, the positive x-axis direction is defined as prograde. Similarly, prograde is defined as the positive y-axis direction if the z and x components of angular momentum are zero. 39

51 kepdt.m The user-defined bodies or heliocentric orbits are orbital elements given for a particular date and must be propagated to the correct Julian date by the module that solves Kepler s problem. The Kepler solver script is a standard algorithm that yields the propagated true anomaly, with all other orbital elements being held constant. planet2planet.m The planet2planet module generates the information needed to define the heliocentric trajectory legs between each node of the mission. The module uses input information about the nodes, such as what planet, user-defined body/orbit, or DSM is appropriated for each node. The heliocentric location vector coinciding with a planet is determined by calling the planetary ephemerides data function developed by the Jet Propulsion Laboratory (JPL) [25, 24]. The location vector at a user-defined body or heliocentric orbit is found by calling the kepdt function and converting the orbital elements to rectangular Cartesian coordinates. The DSM option already provides the heliocentric location vector as an input. All necessary transformations are made to convert the location vectors to heliocentric rectangular Cartesian coordinates of the mean ecliptic and mean equinox of J2000. With the appropriate node locations evaluated, the necessary information is used by the Lambert Targeter module to generate the heliocentric velocities at the nodes. planetinfo.m All planet specific data is provided by the planetinfo module. The types information stored in the module are either constants, such as gravitational parameter and mean 40

52 equatorial radius, or time dependent data, including rotational axis direction and prime meridian location. The time dependent data is generated by using the Julian date of each node at the current iteration. mcmguess.m When using a DSM in the interplanetary trajectory, the mcmguess module checks if a midcourse maneuver or space burn is selected and how many consecutive DSMs there are. If the space burn option is selected, the user provided heliocentric location vector for the DSM is formatted and added to the initialized optimization parameters. If the midcourse maneuver option is selected, the heliocentric node locations outside of the consecutive DSMs are used to compute the initial guess location vectors for the DSMs. The node location prior to the first DSM and the node location after the last DSM in the consecutive sequence are used to determine an average radial distance stepped between all the consecutive DSMs. For example, if three consecutive midcourse maneuvers are selected between two planets, the heliocentric radius of the first DSM is located at 1/4 the radial distance between the planets. The heliocentric radius of the second DSM is located at 1/2 the radial distance between the planets, and the third DSM is at 3/4 of the way between the planets. Then the total angle between the surrounding nodes is determined. The DSM locations are fully defined by being evenly distrusted at equal angles along the plane between the surrounding nodes. If the total trajectory of the consecutive DSMs is intended to cover multiple orbital revolutions, the input parameter revig directs the full angular swath to be split evenly among the DSMs. Finally, the heliocentric locations for the midcourse maneuvers are formatted and added to the initialized optimization 41

53 parameters. The optimizer will then adjust the locations of the DSMs to better suit the trajectory. Some DSM maneuvers may be driven to zero, indicating that a DSM was not required during this trajectory leg. DSM (Midcourse Maneuver or Space Burn) Once the location vector for the DSM is initialized by mcmguess, the optimization process varies the location vector according to how it best minimizes the total V of the trajectory. Since the DSM location is in heliocentric coordinates, the V is simply the difference between entering and exiting heliocentric velocity vectors at the node. Because of the simplicity of the DSM scripts, separate MATLAB function modules were not necessary for the midcourse maneuver or space burn options. park2hypopt.m The park2hypopt Mission Event Module analytically evaluates the V required to depart a user-defined parking orbit about a specified planet. The algorithm uses the given orbital elements for the parking orbit and converts them into rectangular Cartesian coordinates. The required V is previously calculated and converted along with all other necessary parameters into a planetocentric frame of the planet s mean equator of date. The optimal hyperbolic trajectory is analytically determined with the assumption that the parking orbit s ground track contains the declination of the departure asymptote. This condition is checked by comparing the declination of the departure V asymptote to the inclination of the orbit. If the inclination of the orbit is greater than the declination of the departure asymptote, then the most 42

54 efficient hyperbolic transfer geometry is achievable. If the parking orbit s inclination is less, it is changed to equal the angle of the departure asymptote in order to guarantee an efficient hyperbolic transfer trajectory. The algorithms that determine the V needed to complete the trajectory are described in detail in the next section. hyp2parkopt.m The hyp2parkopt Mission Event Module s equations and methodology are similar to the park2hypopt module, but formulated to analytically evaluate the V required to enter into a user-defined parking orbit about a specified planet from a hyperbolic trajectory. park2hypd.m The park2hypd Mission Event Module minimizes the V required to depart a userdefined parking orbit about a specified planet by varying the parking orbit s Ω and ω elements. The unique feature of this module compared to park2hypopt is that it allows the parking orbit inclination to be a fixed value. An optimal parking orbit and hyperbolic trajectory are determined with this constraint. The optimization process in the Mission Event Module is independent from the primary design tool optimization process. This method compares the node s best V value for the mission event scenario at each primary optimization iteration. If the module s optimization needs were consolidated into the primary optimization process, handling the primary optimization parameter configuration would become complex and potentially detrimental to the optimization efficiency. hypa2park.m 43

55 Similar to park2hypd module s equations and methodology, hypa2park minimizes the V required to enter into a user-defined parking orbit about a specified planet from a hyperbolic trajectory by varying the parking orbit s Ω and ω elements. vinf2hypd.m The vinf2hypd Mission Event Module minimizes the V needed to achieve the required hyperbolic trajectory from the user-defined launch vehicle hyperbolic trajectory by varying the Ω and ω elements of the launch vehicle trajectory. The V and launch inclination define the orientation of the launch vehicle s available hyperbolic trajectory. The launch trajectory inclination is assumed to be the proper value that accompanies the V capability for the launch vehicle. Typically the inclination is the latitude of the launch site for the most efficient trajectory. The periapsis altitude allows the user to define the altitude where the spacecraft separates from the launch vehicle and an additional V may be performed if necessary to achieve the required hyperbolic trajectory. The V is applied as soon as possible after the launch process is complete because the orbital velocity is the greatest and therefore the most efficient time to perform a V maneuver. The user defines if excess V available from the launch vehicle trajectory is detrimental, which would apply a V maneuver to match the required V, or acceptable and no V maneuver would be necessary. hypa2vinf.m The hypa2vinf Mission Event Module is similar to the vinf2hypd module, where the methodology is the same but the equations are adapted to a planetary entry 44

56 trajectory. The module minimizes the V needed to alter an arrival hyperbolic trajectory and match the user-defined entry conditions by varying the Ω and ω elements of the entry trajectory. User-Defined Body/Orbit The location vector of the user-defined celestial body or heliocentric orbit is determined by the planet2planet module at the Julian date of the current iteration. Since the user-defined body is assumed to have a negligible gravitational field, the only available arrival maneuver is a heliocentric rendezvous. This option is most useful for missions involving asteroid rendezvous. Similar to the DSM calculations, the required V to rendezvous with the user-defined body or heliocentric orbit is the difference between the entering and exiting velocity vectors at the node. Due to the simplicity of the script, separate MATLAB function modules were not necessary for the user-defined celestial body or heliocentric orbit options. flybyp.m The powered gravity assist Mission Event Module determines the most efficient location about a planet for a V maneuver by analyzing the scenario characteristics of the current iteration. First, the maximum natural (unpowered) gravitational bend angle, Φ g, about the planet is compared to the bend angle required, Φ r. The entering V + and exiting V magnitudes are also compared. These comparisons direct which of the entering or exiting natural hyperbolic trajectory legs the V maneuver will be applied on, which is described in further detail in Section If the flyby periapsis radius is fixed as directed by the optr parameter, the minimum V 45

57 gravity assist is found by varying the true anomaly on the leg that the maneuver is applied. If the optr parameter allows the flyby periapsis radius to be varied, then an initial guess radius is determined and the minimum V gravity assist is found by varying the true anomaly and the periapsis radius. There exist two minima that the optimization process may encounter, depending on the initial true anomaly guess. If initially at periapsis, ν = 0, the minimum V will be found near the periapsis, while if true anomaly is initially in the neighborhood of the planet s SOI, the optimizer will drive the true anomaly to the associated value for r =. This divergence is avoided by limiting the true anomaly to the value associated with the planet s SOI radius, which is chosen to be consistent with the patched conic assumptions. One of the minima is the most efficient and is chosen if the optsoi parameter indicates so; otherwise only the near periapsis value is determined. flybyunp.m The unpowered gravity assist Mission Event Module is similar to the powered gravity assist module, except that there is no independent optimization process to vary true anomaly. Early iterations of the unpowered module will typically have a nonzero V, but the optimization process attempts to reduce the V to a negligible value. The unpowered gravity assist module analytically determines the necessary V to complete the gravity assist trajectory with the current iteration s flyby geometry. This is accomplished by assuming the V occurs at the entering or exiting leg s periapsis. The periapsis radius is directed by the optr parameter to either be fixed at the user-defined value or to be determined for the specific flyby geometry of the iteration. The periapsis maneuver assumption streamlines the primary opti- 46

58 mization process. It removes extra local minima created by additional optimization parameters. If the entire trajectory is properly configured, the V for the unpowered maneuver will diminish to a small number comparable to zero. In the case that an unpowered gravity assist requires a significant V that does not diminish to zero, then the user will likely find a slightly more efficient V using the powered gravity assist option at the particular node. This is because the unpowered option is only efficient if the V reduces to zero. A non-zero unpowered gravity assist is basically a powered gravity assist without the ability to find the best V maneuver location Optimization Function When investigating a trajectory design, the initial input values provided by the user will almost never produce the most efficient trajectory with regard to V. Yet, initial guesses are necessary to initiate the optimization procedure. The optimization process adjusts specified parameters of the trajectory in order to find the configuration that yields the minimum total V used by the spacecraft while accomplishing the mission goals. Though optimization procedures are usually capable of reaching a minimum from initial parameter values that are relatively far from their optimal values, the likelihood of the process finding a better minimum (or a minimum at all) is greatly increased by providing a good initial guess in the neighborhood of the intended minimum. In order for the user to quickly determine if the chosen trajectory input values are close to the desired configuration, the design tool offers the option to bypass the optimization process and determine the trajectory with the fixed input values. This option allows the user to quickly generate trajectories, judge what the effects are of changing specific inputs, and find a 47

59 better initial trajectory configuration for the optimization process. This option can also be used as a sensitivity tool to evaluate the characteristics of the optimization space by trying various boundary conditions of the trajectory configuration. This gives the user a better idea of the entire optimization space. The existing MATLAB optimization functions fminunc and fminsearch were chosen to be the primary optimization method of the trajectory design tool because of the adaptable and proven performance it provides. Each optimization function has unique characteristics which can be utilized by the user to increase convergence speed or improve trajectory performance, depending on the situation. The fminunc function accepts a vector of scalar optimization parameters as an input and calls the trajectory generating script for a scalar total V value as the performance index. The function minimizes the total V by generating numerical partial derivatives of the performance index with respect to each optimization parameter. The partial derivatives form a gradient that guides the changes made to each optimization parameter. The updated optimization parameter is then used to begin the next iteration where the process is repeated. Since fminunc follows a gradient toward a potential minimum, the optimization process may lead to finding a local minimum, therefore it is advisable that the user explore many variations of trajectory inputs, especially the initial node Julian date and TOFs. The fminsearch function also uses a vector of scalar optimization variables and uses the trajectory s total V as a performance index. The main difference between the optimization functions is that fminsearch does not use numerical derivatives or gradients to minimize the performance index. Using a simplex search 48

60 method, fminsearch is a direct optimization method of Lagarias et al. [10] that tests the search space in the neighborhood of the current optimization parameters and updates each parameter that reduces the performance index. A detailed description of the simplex method as found in MATLAB documentation [11] is as follows : If n is the length of x, a simplex in n-dimensional space is characterized by the n+1 distinct vectors that are its vertices. In two-space, a simplex is a triangle; in three-space, it is a pyramid. At each step of the search, a new point in or near the current simplex is generated. The function value at the new point is compared with the function s values at the vertices of the simplex and, usually, one of the vertices is replaced by the new point, giving a new simplex. This step is repeated until the diameter of the simplex is less than the specified tolerance. Without being required to follow a gradient, the simplex method is capable of bypassing a local minimum for a better performing minimum, while the fminunc method might converge to the local minimum guided by the gradient. The avoidance of local minima is not guaranteed by the fminsearch function, but the possibility is more likely than the fminunc function in many situations. The fminunc function has been found to converge to a minimum faster when compared to the fminsearch function for many trajectory configurations. 49

61 3.3 Trajectory Formulation Assumptions The assumptions for the trajectory design tool are much less restrictive on the trajectory configuration as compared to the assumptions previously stated for basic patched conics. The major difference between the basic patched conic method and the method used in the design tool is that the tool is tailored to compute all aspects of the trajectory in three dimensions. The basic patched conic method outlined in Section 2.2 is typically done in two dimensions due to the time consuming process of hand calculations or of programing with a patchwork of computer scripts. The design tool uses impulsive V maneuvers and the separation of heliocentric and planetocentric trajectory legs as previously described in the basic patched conics section. The planetary location vectors are determined from JPL s DE405 ephemerides data function. The heliocentric trajectory legs are determined by a multiple revolution Lambert Targeting routine. The design tool also assumes that the trajectory encounters the gravitational influence of a planet only when directed by the mission event sequence. The heliocentric trajectory vectors are defined in rectangular Cartesian coordinates relative to the mean ecliptic and equinox of J2000 as defined in the Explanatory Supplement to the Astronomical Almanac (Seidelmann 1992) [7]. The planetocentric trajectory vectors are defined in rectangular Cartesian coordinates relative to the equator and right ascension of the ascending node of the specific planet at the iteration s current Julian date. The rotation of planets surfaces is not considered and launch and entry type mission events are assumed to be aligned with the launch or landing site locations (if applicable). The TOFs used by the design tool only apply to heliocentric trajectory segments, while 50

62 planetocentric segments are assumed to occur instantaneously. The true length of time required to complete typical trajectories about a planet are measured in hours. When compared to the hundreds of days that are required for typical heliocentric trajectory legs, the planetocentric trajectories do appear to occur in an instant [2] Heliocentric Trajectory Legs The first major set of calculations of the design process is determining the heliocentric trajectory legs. Since these values directly impact all other computations in the trajectory design process, the locations and velocities of the celestial bodies at each node must be of the highest accuracy available. In order to preserve the accuracy throughout the computational process, the mean ecliptic and mean equinox of J2000 coordinate frame is chosen for heliocentric legs so that location and velocity vectors can consistently transition to and from planetary frames Planetary Locations The location and velocity vectors of the planets and the dwarf planet Pluto are retrieved from the JPL ephemerides function, pleph. The function requires the Julian date and the planetary position number such as 1 for Mercury, 4 for Mars, 9 for Pluto, etc. as inputs. The pleph function looks up the appropriate polynomial coefficients and evaluates accurate location and velocity vectors for the precise date. The vectors are returned as coordinates in the mean equator and mean equinox of J2000 frame and are transformed to the mean ecliptic frame by rotating about the x-axis as seen in example below, where an arbitrary location vector r equatorial is transformed into r ecliptic. The rotation angle is the obliquity of the ecliptic at epoch 51

63 J2000, ε = [7]. r ecliptic = cosε sinε 0 sinε cosε r equatorial (3.3.1) The DE405 data file provides accurate ephemerides for the time range of 1600 AD to 2200 AD. For different date ranges or various changes in accuracy, the planetary ephemerides data file can be updated with other data files as available User-defined Body or Heliocentric Orbit Locations A celestial body or heliocentric orbit can be defined for rendezvous in the trajectory. The required inputs are semimajor axis, eccentricity, inclination, right ascension of ascending node, argument of periapsis, true anomaly, and the Julian date for which these orbital elements are referenced, [ a e i Ω ω ν JD ]. The orbital elements are assumed to be fixed in time except for true anomaly. The true anomaly gives the precise location in the orbit and is propagated from the referenced Julian date (JD) to the desired Julian date of the node s current iteration. The appropriate true anomaly is found by using an algorithm for solving Kepler s problem from Vallado, Algorithm 7[2]. Kepler s equation is commonly seen as M = E esine, (3.3.2) where mean anomaly, M, is related to eccentric anomaly, E. In this version of Kepler s solution, the calculations are sorted into the different conic sections by eccentricity. The orbit s true anomaly is converted to the appropriate anomaly for 52

64 its eccentricity, eccentric, parabolic, or hyperbolic anomaly. An iterative algorithm is employed with a specified initial mean and eccentric anomaly, M 0 and E 0, as well as the difference in Julian dates and mean motion, t and n. For an elliptical orbit M 0 = E 0 esine 0 M = M 0 + n t E = M ± e (depending on value of M) (3.3.3) E n+1 = E n + M E n + esine n 1 ecose n, where the iterative equation is looped until E n+1 E n is less than a specified tolerance, in this case tol = For a hyperbolic orbit using an initial hyperbolic anomaly H 0, M 0 = esinh(h 0 ) H 0 M = 0 + n t { M H = M ± e (depending on value of M) M e 1 (depending on value of e) H n+1 = H n + M esinh(h n) + H n, ecosh(h n ) 1 where the iterative equation is looped until H n+1 H n is less than tol. (3.3.4) For a parabolic orbit using an initial parabolic anomaly B 0, the initial mean anomaly, angular momentum vector (h), and the semiparameter (p) is found. 53

65 M 0 = B 0 + B3 0 3 h = r V (3.3.5) p = h µ 2 These values are then used to solve Barker s equation analytically [2], where n p is the mean motion of the parabola and angles s and w are used to relate the parabolic anomaly B to change in time t. µ n p = 2 p 3 cot(2s) = 3 2 n p t (3.3.6) tan 3 (w) = tan(s) B = 2cot(2w) After evaluating the respective anomaly at the desired Julian date, the anomaly is converted into true anomaly to complete the standard set of orbital elements for the Julian date of the node s iteration. The new set of orbital elements is then converted to heliocentric location and velocity vectors Departure Options Depart Parking Orbit Analytically The user defines the orbital elements of a parking orbit from which the spacecraft transfers (with a V maneuver) onto a hyperbolic trajectory toward the 54

66 next mission objective. The hyperbolic trajectory is defined by the exiting V at the planet and the parking orbit s periapsis location vector. The parking orbit is defined with respect to the equator and node of the planet at the current iteration s date. The planet s equator is defined by the right ascension α and declination δ of the planet s north pole at the date. With α and δ at the date retrieved from the planetinfo module, the planetocentric frame can be defined. The heliocentric vectors needed for calculation are converted from the mean ecliptic and equinox of J2000 to the planetocentric frame. The planet s north pole direction unit vector ˆn p in the mean ecliptic frame is found as ˆn p = cosε sinε 0 sinε cosε cosα cosδ sinα cosδ sinδ. (3.3.7) The right ascension of ascending node of the planet s equator ˆΩ is determined by comparing the planet s north pole unit vector to the unit vector of Earth s north pole at J2000. ˆΩ = ˆn e ˆn p ˆn e ˆn p (3.3.8) The last unit vector direction, ˆv, completes the right handed coordinate system, ˆv = ˆn p ˆΩ. (3.3.9) Any required heliocentric vector defined in the mean ecliptic frame is transformed to the planetocentric equatorial frame similar to the following example with V. 55

67 V x V y V z equ = V ˆΩ V ˆv V ˆn p (3.3.10) The periapsis and apoapsis radial distances are determined and converted into units of planetary radii [9]. r p = a(1 e) r a = a(1 + e) d p = r p r pl (3.3.11) d a = r a r pl The typical hyperbolic orbit values and β as defined by Equations and are determined, as well as ν which is the angle measured from the periapsis radial direction to the hyperbolic asymptote, ν = π β. (3.3.12) The velocity of a circular orbit with the same periapsis distance is found, followed by the magnitude of the V required to exit the parking orbit onto a coplanar hyperbolic trajectory. V circ = µ r p (3.3.13) 56

68 V = V hyp V park = 2Vcirc 2 +V 2 2d a V circ (3.3.14) d p + d a In order to assure a coplanar transfer, the inclination of the parking orbit is compared to the inclination of the hyperbolic trajectory. The coplanar transfer is achievable if the inclination of the parking orbit is greater than the declination of the hyperbolic orbit s V. Declination and right ascension of a vector is defined as shown with the V [9]. ( ) δ V = sin 1 V z V ( ) α V = tan 1 V y V x (3.3.15) (3.3.16) If i < δ V, then the parking orbit inclination is set to δ V. The collinear periapsis location vector for the parking orbit and hyperbolic trajectory is found by defining the angles β and α, where α describes the two possible orientations of the angular momentum unit vector of the hyperbolic trajectory. β = cos 1 (tanδ V coti) (3.3.17) α = π β ± α V (3.3.18) cosα sini ĥ = sinα sini (3.3.19) cosi r p = r p ( cos(ν ) ˆV + sin(ν ) ( ˆV ĥ )) (3.3.20) 57

69 The impulsive V maneuver vector is found as (ĥ ) rp V = V. (3.3.21) r p With the periapsis location vector and the hyperbolic trajectory values already evaluated, the velocity vector of the hyperbolic trajectory (V hyp ) at the same location is found using a two-body orbital terminal velocity solution developed by Battin[1] V hyp = ( D + 1 ) ( 2 V i + D 1 ) 2 V i rp, (3.3.22) where D is a scaling factor related to the hyperbolic trajectory s geometer. µ D = r p (1 + cosν ) + V 2 4 (3.3.23) The parking orbit periapsis velocity vector is evaluated simply, V p = V hyp V. (3.3.24) The new orbital elements for the parking orbit are computed from the periapsis location and velocity vectors. The V maneuver is transformed into the ecliptic frame for comparison and plotting purposes. The transformation is a series of frame rotations as defined by the ˆn p, ˆΩ, and ˆv vectors. The mathematical operation of transforming from the ecliptic frame to the planet s equatorial frame is simple compared to the reverse operation. The north pole direction vector in the ecliptic frame (ˆn p ) is converted into declination and right ascension, δ ε and α ε. A 58

70 frame rotation of δ ε about the y-axis, 2ROT δ, and a frame rotation of α ε about the z-axis, 3ROT α, are applied after the vector s equatorial frame x-axis is adjusted for a proper transformation. 2ROT δ = 3ROT α = cos( δ ε ) 0 sin( δ ε ) sin( δ ε ) 0 cos( δ ε ) cos( α ε ) sin( α ε ) 0 sin( α ε ) cos( α ε ) (3.3.25) (3.3.26) The equatorial frame s x-axis is adjusted with a z-axis frame rotation by the angle ϕ found computing the angular difference between ˆΩ transformed to the equatorial frame ( ˆΩ e ) and the equatorial frame s x-axis. ϕ = tan 1 ( ˆΩ ey 3ROT ϕ = ˆΩ ex ) cos(ϕ) sin(ϕ) 0 sin(ϕ) cos(ϕ) (3.3.27) (3.3.28) The transformed V maneuver in the ecliptic frame is defined as V = 3ROT α 2ROT δ 3ROT ϕ V (3.3.29) Finally, the time needed for the hyperbolic trajectory to reach the planet SOI from periapsis (t SOI ) is determined for plotting purposes, where a hyp, e hyp, M hyp, h, and F are the semimajor axis, eccentricity, mean anomaly, angular momentum, and hyperbolic anomaly for the hyperbolic trajectory respectively [2]. 59

71 a hyp = µ V 2 e hyp = 1 + r pv 2 µ h = r p V hypp ( ) 1 F = cosh 1 rsoi /a hyp e hyp M hyp = e hyp sinh(f) F (3.3.30) t SOI = h 3 M hyp µ 2 ( e 2 hyp 1 ) 3/ Depart Parking Orbit (fixed i) The option to leave a parking orbit with a fixed inclination requires an independent optimization process to find the best orientation for the minimum V to achieve the (not necessarily coplanar) hyperbolic trajectory. Similar to the analytical parking orbit departure, the planet s equatorial coordinate frame is defined and the necessary heliocentric vectors are converted into the planetocentric frame. The, β, and ν hyperbolic trajectory values are found. The Ω and ω of the parking orbit are varied by the MATLAB optimizing function. They are the only elements necessary for change to minimize the V, because the hyperbolic transfer need only achieve a V that is parallel to the desired V asymptote, as seen in Figure At each iteration of the optimization process, the current values for Ω and ω along with the other fixed orbital elements are converted into location and velocity vectors at the parking orbit s periapsis. Using the periapsis location vector and the information already evaluated from the hyperbolic trajectory, the velocity vector of 60

72 Figure 3.3.1: Potential hyperbolic trajectories to match V asymptote [Source: Curtis [3]] the hyperbolic trajectory is determined in the same manner as above in Equation With the parking orbit periapsis coincident with the hyperbolic trajectory location, the V for the maneuver is determined as V = V hyp V p. (3.3.31) The remaining calculations of the module are identical to the analytical departure module Launch Vehicle Departure The hyperbolic trajectory values, β, and ν are determined from the required V as given by the heliocentric trajectory legs. The V provided by the user defines the available excess velocity that a launch vehicle trajectory is able to pro- 61

73 Figure 3.3.2: Potential launch vehicle trajectories from launch site [Source: Curtis [3]] vide. The necessary vectors are transformed into the planet s equatorial frame in the previously defined method. Since a typical launch vehicle s V capability assumes a trajectory inclination equal to the launch site latitude, Figure 3.3.2, the inclination value defined by the user is assumed to be fixed. The fixed inclination requirement prohibits making a coplanar assumption of the transfer from the launch vehicle trajectory onto the required hyperbolic trajectory. Similar to the differences between options of departing a parking orbit, the orientation of the launch vehicle trajectory must be optimized by varying the orbital elements Ω and ω in order to minimize the V to transfer onto the required hyperbolic trajectory. The periapsis radius is defined by the user as the radial distance when the launch vehicle has completed its thrusting maneuvers. The periapsis radius is used to determine the launch vehicle trajectory s semimajor axis and ec- 62