connor/thesis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Getting pretty close on the final review

Browse Source
This commit is contained in:
Connor
2022-03-13 23:34:38 -06:00
parent 7fcdb26ab7
commit e36b99b84c
22 changed files with 2386 additions and 623 deletions
Download Patch File Download Diff File Expand all files Collapse all files

268
LaTeX/approach.tex
View File

@@ -1,47 +1,50 @@
\chapter{Algorithm Overview} \label{algorithm}
In this section, we will review the actual execution of the algorithm developed. As an
overview, the routine was developed to enable the determination of an optimized spacecraft
trajectory from the selection of some very basic mission parameters. Those parameters
This thesis will attempt to develop an algorithm for the preliminary analysis of feasibility in
designing a low-thrust interplanetary mission to an outer planet by leveraging a monotonic basin
hopping algorithm. In this section, we will review the actual execution of the algorithm
developed. As an overview, the routine was designed to enable the determination of an optimized
spacecraft trajectory from the selection of some very basic mission parameters. Those parameters
include:
\begin{itemize}
\item Spacecraft dry mass
\item Thruster Specific Impulse
\item Thruster Maximum Thrusting Force
\setlength\itemsep{-0.5em}
\item Spacecraft dry mass in kilograms
\item Thruster Specific Impulse in seconds
\item Thruster Maximum Thrusting Force in Newtons
\item Thruster Duty Cycle Percentage
\item Number of Thruster on Spacecraft
\item Total Starting Weight of the Spacecraft
\item A Maximum Acceptable $V_\infty$ at arrival and $C_3$ at launch
\item The Launch Window Timing and the Latest Arrival
\item Number of Thrusters on Spacecraft
\item Total starting mass of the Spacecraft in kilograms
\item A Maximum Acceptable $V_\infty$ at arrival in kilometers per second
\item A Maximum Acceptable $C_3$ at launch in kilometers per second squared
\item The Launch Window Boundaries
\item The Latest Arrival Date
\item A cost function relating the mass usage, $v_\infty$ at arrival, and $C_3$ at
launch to a cost
\item A list of flyby planets starting with Earth and ending with the destination
\end{itemize}
Which allows for extremely automated optimization of the trajectory, while still providing
the mission designer with the flexibility to choose the particular flyby planets to
investigate.
Which allows for an automated approach to optimization of the trajectory, while still providing
the mission designer with the flexibility to choose the particular flyby planets to investigate.
This is achieved via an optimal control problem in which the ``inner loop'' is a
non-linear programming problem to determine the optimal low-thrust control law and flyby
parameters given a suitable initial guess. Then an ``outer loop'' monotonic basin hopping
algorithm is used to traverse the search space and more carefully optimize the solutions
found by the inner loop.
This is achieved via an optimal control problem in which the ``inner loop'' involves solving a
TPBVP to find the optimal solution given a suitable initial guess. Then an ``outer loop''
monotonic basin hopping algorithm is used to traverse the search space and determine the global
optima by repeated use of control perturbation and the inner loop.
\section{Trajectory Composition}
In this thesis, a specific nomenclature will be adopted to define the stages of an
interplanetary mission in order to standardize the discussion about which aspects of the
software affect which phases of the mission.
interplanetary mission in order to standardize the discussion about which aspects affect
which phases of the mission.
Overall, a mission is considered to be the entire overall trajectory. In the context of
this software procedure, a mission is taken to always begin at the Earth, with some
initial launch C3 intended to be provided by an external launch vehicle. This C3 is not
fully specified by the mission designer, but instead is optimized as a part of the
overall cost function (and normalized by a designer-specified maximum allowable value).
Overall, an end-to-end trajectory is considered to be the entire overall trajectory. In this
context a trajectory begins at the Earth, with some initial launch C3 intended to be
provided by an external launch vehicle. This C3 is not fully specified by the trajectory
designer, but instead can be considered a part of the overall cost function for optimization
of the Two-Point Boundary Value Problem.
This overall mission can then be broken down into a variable number of ``phases''
This overall trajectory can then be broken down into a variable number of ``phases''
defined as beginning at one planetary body with some excess hyperbolic velocity and
ending at another. The first phase of the mission is from the Earth to the first flyby
planet. The final phase is from the last flyby planet to the planet of interest.
@@ -59,11 +62,11 @@
minimum altitude above the surface or atmosphere of the flyby planet.
\end{enumerate}
These conditions then effectively stitch the separate mission phases into a single
coherent mission, allowing for the optimization of both individual phases and the entire
mission as a whole. This nomenclature is similar to the nomenclature adopted by Jacob
Englander in his Hybrid Optimal Control Problem paper, but does not allow for missions
with multiple targets, simplifying the optimization.
These conditions then effectively stitch the separate phases into a single coherent mission,
allowing for the optimization of both individual phases and the entire trajectory as a whole.
This nomenclature is similar to the nomenclature adopted by Jacob Englander in his Hybrid
Optimal Control Problem paper, but does not allow for trajectories with multiple targets,
simplifying the optimization.
\section{Inner Loop Implementation}\label{inner_loop_section}
@@ -77,15 +80,36 @@
into an NLP, but there are essentially three primary routines involved in the inner
loop. A given state is propagated forward using the LaGuerre-Conway Kepler solution
algorithm, which itself is used to generate powered trajectory arcs via the
Sims-Flanagan transcribed propagator. Finally, these powered arcs are connected via a
multiple-shooting non-linear optimization problem. The trajectories describing each
phase complete one ``Mission Guess'' which is fed to the non-linear solver to generate
one valid trajectory within the vicinity of the original Mission Guess.
Sims-Flanagan transcribed propagator. Finally, these powered arcs are connected using a
multiple-shooting approach driven optimization. The trajectories describing each
phase complete one ``Guess'' which is fed to the non-linear solver to generate
one valid trajectory within the vicinity of the original Guess.
In this formulation the cost function $F$ is a user provided function of the input Guess.
The constraint function $G$ defines the following conditions that must be met:
\begin{itemize}
\item For every phase other than the final:
\begin{itemize}
\item The minimum periapsis of the hyperbolic flyby arc must be above some
user-specified minimum safe altitude.
\item The magnitude of the incoming hyperbolic velocity must match the magnitude
of the outgoing hyperbolic velocity.
\item The spacecraft position must match the planet's position (within bounds)
at the end of the phase.
\end{itemize}
\item For the final phase:
\begin{itemize}
\item The spacecraft position must match the planet's position (within bounds)
at the end of the phase.
\item The final mass must be greater than the dry mass of the craft.
\end{itemize}
\end{itemize}
\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{flowcharts/nlp}
\caption{A flowchart of the Non-Linear Problem Solving Formulation}
\caption{A flowchart of the TPBVP Solution Approach}
\label{nlp}
\end{figure}
@@ -141,7 +165,9 @@
For example, from the orbital parameters of a certain state, the orbital period can
be determined. If the system is then propagated for an integer multiple of the orbit
period, the state should remain exactly the same as it began. In
Figure~\ref{laguerre_plot} an example of such an orbit is provided.
Figure~\ref{laguerre_plot} an example of such an orbit is provided in which the final
state was tested against the initial state and found to be equal to the original to
within $1 \times 10^{-12}$ in magnitude.
\begin{figure}[H]
\centering
@@ -150,7 +176,6 @@
approach to solving Kepler's Problem}
\label{laguerre_plot}
\end{figure}
% TODO: Consider adding a paragraph about the improvements in processor time
\subsection{Sims-Flanagan Propagator}
@@ -179,10 +204,14 @@
\label{sft_plot}
\end{figure}
Figure~\ref{sft_plot} shows that the Sims-Flanagan transcription model can be used
to effectively model these types of orbit trajectories. In fact, the Sims-Flanagan
model is capable of modeling nearly any low-thrust trajectory with a sufficiently
high number of $n$ samples.
Figure~\ref{sft_plot} shows that the Sims-Flanagan transcription model can be used to
effectively model these types of orbit trajectories by plotting a very common ``spiral''
trajectory in which the thrust is always on and the thrust direction is always in line
with the direction of the velocity vector. As can be seen, this produces a spiraling
trajectory in which the distance between spirals becomes increasingly larger as the
trajectory achieves higher and higher distances from the Sun. In fact, the Sims-Flanagan
model is capable of modeling nearly any low-thrust trajectory with a sufficiently high
number of $n$ samples.
Finally, it should be noted that, in any proper propagation scheme, mass should be
decremented proportionally to the thrust used. The Sims-Flanagan Transcription
@@ -199,7 +228,8 @@
Where $\Delta m$ is the fuel used in the sub-trajectory, $\Delta t$ is the time of
flight of the sub-trajectory, and $g_0$ is the standard gravity at the surface of
Earth.
Earth. From knowledge of the mass flow rate, we can then decrement the mass
appropriately based on the magnitude of the thrust vector at each point.
\subsection{Non-Linear Problem Solver}
@@ -208,11 +238,11 @@
a (proposed) trajectory. This trajectory need not be valid.
For the purposes of discussion in this Section, we will assume that the inner-loop
algorithm starts with just such a ''Mission Guess``, which represents the proposed
algorithm starts with just such a ''Guess``, which represents the proposed
trajectory. However, we'll briefly mention what quantities are needed for this
input:
A Mission Guess object contains:
A Guess object contains:
\begin{singlespacing}
\begin{itemize}
\item The spacecraft and thruster parameters for the mission
@@ -233,24 +263,25 @@
\end{itemize}
\end{singlespacing}
From this information, as can be seen in Figure~\ref{nlp}, we can formulate the
mission in terms of a non-linear problem. Specifically, the Mission Guess object can
be represented as a vector, $x$, the propagation function as a function $F$, and the
constraints as another function $G$ such that $G(x) = \vec{0}$.
From this information, as can be seen in Figure~\ref{nlp}, we can formulate the mission
in terms of a non-linear programming problem. Specifically, the variables describing the
trajectory contained within the Guess object can be represented as an input vector,
$\vec{x}$, the cost function produced by an entire trajectory propagation as $F$, and
the constraints that the trajectory must satisfy as another function $\vec{G}$ such that
$\vec{G}(\vec{x}) = \vec{0}$.
This is a format that we can apply directly to the IPOPT solver, which Julia (the
programming language used) can utilize via bindings supplied by the SNOW.jl
package\cite{snow}.
IPOPT also requires the derivatives of both the $F$ and $G$ functions in the
formulation above. Generally speaking, a project designer has two options for
determining derivatives. The first option is to analytically determine the
derivatives, guaranteeing accuracy, but requiring processor time if determined
algorithmically and sometimes simply impossible or mathematically very rigorous to
determine manually. The second option is to numerically derive the derivatives,
using a technique such as finite differencing. This limits the accuracy, but can be
faster than algorithmic symbolic manipulation and doesn't require rigorous manual
derivations.
IPOPT also requires the derivatives of both the $F$ and $G$ functions in the formulation
above with respect to the input $\vec{x}$ vector. There are two options for determining
derivatives. The first option is to analytically determine the derivatives, guaranteeing
accuracy, but requiring processor time if determined algorithmically and sometimes
simply impossible or mathematically very rigorous to determine manually. The second
option is to numerically approximate the derivatives, using a technique such as finite
differencing. This limits the accuracy, but can be faster than algorithmic symbolic
manipulation and doesn't require rigorous manual derivations.
However, the Julia language has an excellent interface to a new technique, known as
automatic differentiation\cite{RevelsLubinPapamarkou2016}. Automatic differentiation
@@ -271,10 +302,10 @@
\section{Outer Loop Implementation}
Now we have the tools in place for, given a potential ''mission guess`` in the
Now we have the tools in place for, given a potential ''guess`` in the
vicinity of a valid guess, attempting to find a valid and optimal solution in that
vicinity. Now what remains is to develop a routine for efficiently generating these
random mission guesses in such a way that thoroughly searches the entirety of the
random guesses in such a way that thoroughly searches the entirety of the
solution space with enough granularity that all spaces are considered by the inner loop
solver.
@@ -293,14 +324,14 @@
\label{mbh_flow}
\end{figure}
\subsection{Random Mission Generation}\label{random_gen_section}
\subsection{Random Trajectory Generation}\label{random_gen_section}
At a basic level, the algorithm needs to produce a mission guess (represented by all
of the values described in Section~\ref{inner_loop_section}) that contains random
values within reasonable bounds in the space. This leaves a number of variables open
to for implementation. For instance, it remains to be determined which distribution
function to use for the random values over each of those variables, which bounds to
use, as well as the possibilities for any improvements to a purely random search.
At a basic level, the algorithm needs to produce a guess (represented by all of the
values described in Section~\ref{inner_loop_section}) that contains random values within
reasonable bounds in the space. However, that still leaves the determination of which
distribution function to use for the random values over each of those variables, which
bounds to use, as well as the possibilities for any improvements to a purely random
search.
Currently, the first value set for the mission guess is that of $n$, which is the
number of sub-trajectories that each arc will be broken into for the Sims-Flanagan
@@ -351,22 +382,20 @@
velocity was calculated. However, instead of multiplying the randomly generate unit
direction vector by a random number between 0 and the square root of the maximum
launch $C_3$, bounds of 0 and 10 kilometers per second are used instead, to provide
realistic flyby values.
realistic flyby values\cite{englander2014tuning}.
The outgoing excess hyperbolic velocity at infinity is then calculated by again
choosing a uniform random unit direction vector, then by multiplying this value by
the magnitude of the incoming $v_{\infty}$ since this is a constraint of a
non-powered flyby.
From these two velocity vectors the turning angle, and thus the periapsis of the
flyby, can then be calculated by the following equations:
From these two velocity vectors the turning angle, and thus the periapsis of the flyby,
can then be calculated by Equation~\ref{turning_angle_eq} and the following equation:
\begin{align}
\delta &= \arccos \left( \frac{\vec{v}_{\infty,in} \cdot
\vec{v}_{\infty,out}}{|v_{\infty,in}| \cdot {|v_{\infty,out}}|} \right) \\
r_p &= \frac{\mu}{\vec{v}_{\infty,in} \cdot \vec{v}_{\infty,out}} \cdot \left(
\begin{equation}
r_p = \frac{\mu}{\vec{v}_{\infty,in} \cdot \vec{v}_{\infty,out}} \cdot \left(
\frac{1}{\sin(\delta/2)} - 1 \right)
\end{align}
\end{equation}
If this radius of periapse is then found to be less than the minimum safe radius
(currently set to the radius of the planet plus 100 kilometers), then the process is
@@ -375,17 +404,96 @@
solver.
The final requirement then, is the thrust controls, which are actually quite simple.
Since the thrust is defined as a 3-vector of values between -1 and 1 representing
some percentage of the full thrust producible by the spacecraft thrusters in that
direction, the initial thrust controls can then be generated as a $20 \times 3$
matrix of uniform random numbers within that bound.
Since the thrust is defined as a 3-vector of values between -1 and 1 representing some
percentage of the full thrust producible by the spacecraft thrusters in that direction,
the initial thrust controls can then be generated as a $20 \times 3$ matrix of uniform
random numbers within that bound. The number 20 was chosen as the number of
subtrajectories per phase to provide reasonable fidelity for allowing phases to run
longer (on the order of 2 or 3 orbits) without sacrificing speed per Englander
\cite{englander2012automated}. One possible improvement would be to choose the number
more intelligently based on the expected number of revolutions.
\subsection{Monotonic Basin Hopping}\label{mbh_subsection}
Now that a generator has been developed for mission guesses, we can build the
Now that a generator has been developed for guesses, we can build the
monotonic basin hopping algorithm. Since the implementation of the MBH algorithm
used in this paper differs from the standard implementation, the standard version
won't be described here. Instead, the variation used in this paper, with some
performance improvements, will be considered.
The aim of a monotonic basin hopping algorithm is to provide an efficient method for
completely traversing a large search space and providing many seed values within the
space for an ``inner loop'' solver or optimizer. These solutions are then perturbed
slightly, in order to provide higher fidelity searching in the space near valid
solutions in order to fully explore the vicinity of discovered local minima. This
makes it an excellent algorithm for problems with a large search space, including
several clusters of local minima, such as this application.
The algorithm contains two loops, the size of each of which can be independently
modified (generally by specifying a ``patience value'', or number of loops to
perform, for each) to account for trade-offs between accuracy and performance depending on
mission needs and the unique qualities of a certain search space.
The first loop, the ``search loop'', first calls the random mission generator. This
generator produces two random missions as described in
Section~\ref{random_gen_section} that differ only in that one contains random flyby
velocities and control thrusts and the other contains Lambert's-solved flyby
velocities and zero control thrusts. For each of these guesses, the NLP solver is
called. If either of these mission guesses have converged onto a valid solution, the
lower loop, the ``drill loop'' is entered for the valid solution. After the
convergence checks and potentially drill loops are performed, if a valid solution
has been found, this solution is stored in an archive. If the solution found is
better than the current best solution in the archive (as determined by a
user-provided cost function of fuel usage, $C_3$ at launch, and $v-\infty$ at
arrival) then the new solution replaces the current best solution and the loop is
repeated. Taken by itself, the search loop should quickly generate enough random
mission guesses to find all ``basins'' or areas in the solution space with valid
trajectories, but never attempts to more thoroughly explore the space around valid
solutions within these basins.
The drill loop, then, is used for this purpose. For the first step of the drill
loop, the current solution is saved as the ``basin solution''. If it's better than
the current best, it also replaces the current best solution. Then, until the
stopping condition has been met (generally when the ``drill counter'' has reached
the ``drill patience'' value) the current solution is perturbed slightly by adding
or subtracting a small random value to the components of the mission.
The performance of this perturbation in terms of more quickly converging upon the
true minimum of that particular basin, as described in detail by
Englander\cite{englander2014tuning}, is highly dependent on the distribution
function used for producing these random perturbations. While the intuitive choice
of a simple Gaussian distribution would make sense to use, it has been found that a
long-tailed distribution, such as a Cauchy distribution or a Pareto distribution is
more robust in terms of well chose boundary conditions and initial seed solutions as
well as more performant in time required to converge upon the minimum for that basin.
Because of this, the perturbation used in this implementation follows a
bi-directional, long-tailed Pareto distribution generated by the following
probability density function\cite{englander2014tuning}:
\begin{equation}
1 +
\left[ \frac{s}{\epsilon} \right] \cdot
\left[ \frac{\alpha - 1}{\frac{\epsilon}{\epsilon + r}^{-\alpha}} \right]
\end{equation}
\noindent
Where $s$ is a random array of signs (either plus one or minus one) with dimension
equal to the perturbed variable and bounds of -1 and 1, $r$ is a uniformly
distributed random array with dimension equal to the perturbed variable and bounds
of 0 and 1, $\epsilon$ is a small value (nominally set to $1e-10$), and $\alpha$ is
a tuning parameter to determine the size of the tails and width of the distribution
set to $1.01$, but easily tunable.
The perturbation function then steps through each parameter of the mission,
generating a new guess with the parameters modified by the Pareto distribution.
After this perturbation, the NLP solver is then called again to find a valid
solution in the vicinity of this new guess. If the solution is better than the
current basin solution, it replaces that value and the drill counter is reset to
zero. If it is better than the current total best, it replaces that value as well.
Otherwise, the drill counter increments and the process is repeated. Therefore, the
drill patience allows the mission designer to determine a maximum number of
iterations to perform without improvement in a row before ending the drill loop.
This process can be repeated essentially ''search patience`` number of times in
order to fully traverse all basins.