Content uploaded by Taylor Reynolds

Author content

All content in this area was uploaded by Taylor Reynolds on Jan 11, 2020

Content may be subject to copyright.

A Real-Time Algorithm for Non-Convex

Powered Descent Guidance

Taylor P. Reynolds∗

, Danylo Malyuta∗

,

Mehran Mesbahi†

, Beh¸cet A¸cıkme¸se†

,

Dept. of Aeronautics & Astronautics, University of Washington, Seattle, WA 98195, USA

and

John M. Carson III‡

NASA Johnson Space Center, Houston, TX 77058, USA

The on-board solution of constrained optimal control problems is a key technology for future

entry, descent and landing systems. The constraints that must be satisﬁed to enable advanced

navigation routines require powered descent guidance solutions that consider the coupled ro-

tation and translation of the vehicle, leading to a non-convex 6-degree-of-freedom powered

descent guidance problem. This paper builds on previous work and reﬁnes a successive convex-

iﬁcation algorithm to be compatible with common ﬂight code requirements. We highlight the

aspects of each algorithmic step that are especially relevant for maximizing the computational

performance. A case study is presented using the most general landing problem for which

the optimal solution is theoretically known and that contains both rotational and translational

states. We demonstrate that the real-time implementation achieves less than 1% sub-optimality

with runtimes on the order of 100 ms on a single 3.2 GHz Intel i5 core with 8 GB of RAM.

These results suggest that the same design methodology applied to the full 6-degree-of-freedom

landing problem is capable of producing fast enough runtimes to be viable for future entry,

descent and landing systems.

I. Introduction

Powered Descent Guidance (PDG) is the terminal phase of the entry, descent and landing sequence in which

a lander uses its rocket engine(s) and, optionally, its reaction control system to maneuver from an initial state

to a soft touchdown. Powered descent is a fundamental technology for safe and precise landing, and the search

for a general and reliable PDG solution has been of increasing importance for extraterrestrial spaceﬂight. Space

launch continues to be expensive, ranging from above $10,000 kg−1during the Space Shuttle era to a current low

of $3,000 kg−1for the Falcon 9,1with high costs predicted for the Space Launch System.2To help reduce launch

mass (and therefore mission cost), PDG solutions typically seek to minimize the use of propellant. For example,

there is evidence that the (sub-optimal) polynomial guidance algorithm used during the Apollo program could

come within 16 kg of the minimum fuel usage3for that problem.

Future space missions have a strong need for a PDG algorithm that satisﬁes the following requirements.4To

account for lander pointing requirements imposed by sensing architectures, the algorithm must be capable of

handling a large suite of continuous and discrete input and state constraints. Consequently, trajectory planning

must at least consider the 6-degree-of-freedom (DoF) rigid body rotation and translation of the vehicle. Second,

future robotic landers will have to navigate challenging environments such as volcanic vents and jagged blades

of ice,5, 6 while human missions are likely to be preceded by cargo missions and will require that landings occur

in close proximity.7To support hazard avoidance and real-time intelligent re-planning, the algorithm must have

predictable convergence behaviour and be real-time capable on computationally constrained hardware. Lastly,

the algorithm must function autonomously so that it can be used by both robotic and crewed missions. Motivated

by the presence of water ice, future missions to the Moon in particular will target its south pole.8The low tilt

∗Ph.D. Candidate, AIAA Student Member {tpr6,danylo}@uw.edu

†Professor, AIAA Associate Fellow, {mesbahi,behcet}@uw.edu

‡SPLICE Principal Investigator, AIAA Associate Fellow, john.m.carson@nasa.gov

1 of 24

American Institute of Aeronautics and Astronautics

of the Moon’s spin axis creates extreme light-dark lighting conditions at the poles, further emphasizing the need

for a fully automated sensor-based PDG sequence.9

The ﬁrst step towards a real-time constrained 6-DoF PDG algorithm was taken during the Apollo era when the

analytic solution to a fuel-optimal 1-DoF purely vertical descent was found by Meditch.10 Around the same time,

Lawden formulated the necessary conditions of optimality for a more general fuel-optimal 3-DoF problem that

considers the mass and translational dynamics.11, 12 However, the computational resources required to solve the

necessary conditions (e.g., using shooting methods) were not yet readily available. More recently, D’Souza found

closed-form solutions to the necessary conditions for a mixed minimum-energy minimum-time unconstrained 3-

DoF problem.13 Using modern software, Topcu, Casoliva and Mease compared the attainable solution quality

for the fuel-optimal 3-DoF problem to the necessary conditions of optimality derived by Lawden.14, 15 Their

focus was not to develop a real-time PDG algorithm, as they used nonlinear programming methods that do

not meet the previously mentioned computational requirements. A real-time capable algorithm that solves the

3-DoF necessary conditions using nonlinear root ﬁnding techniques has been developed by Lu.16, 17 However,

this algorithm has limited ability to enforce state constraints that may be required by future missions.

Over the past 40 years, research in numerical optimization has developed a family of interior point methods that

can solve optimization problems to global optimality in polynomial time and with guaranteed convergence.18, 19

These much-needed properties for an on-board PDG algorithm stand in stark contrast to both shooting and

nonlinear programming. The only limitation, roughly speaking, is that problems must be convex .20 However,

A¸cıkme¸se and Ploen recognized that the fuel-optimal 3-DoF problem with several important constraints like the

approach angle and rocket engine thrust lower- and upper-bounds can be expressed as a convex optimization

problem and solved to global optimality.21 The method, termed lossless convexiﬁcation, was the ﬁrst to solve the

3-DoF problem with meaningful constraints in a fashion suitable for robust on-board implementation. Over the

course of the next decade, the method was expanded to handle fairly general non-convex input sets,22 minimum-

error landing and thrust pointing constraints,23–25 classes of aﬃne and quadratic state constraints,26–28 classes

of nonlinear (mixed-integer) dynamics,29 and even certain binary constraints without resorting to mixed-integer

programming.30, 31 In principle, all lossless convexiﬁcation results are real-time implementable as they require

solving one or a (small) bounded sequence of problems via Second-Order Cone Programming (SOCP). Fast

and eﬃcient SOCP solvers that use only static memory allocation are available.32–34 As an added beneﬁt, the

solvability of 3-DoF problem using lossless convexiﬁcation is guaranteed anywhere within a well-deﬁned convex

set that can be computed during mission design.35–37

However, a major limitation inherent to any 3-DoF PDG algorithm is that the computed trajectory only

respects translation dynamics and constraints related to either translation or the thrust vector. 3-DoF PDG

methods do not model attitude dynamics, and instead assume that the attitude is controlled by a much faster

inner control loop. More importantly, 3-DoF methods cannot produce solutions that are guaranteed to respect

sensing requirements such as line-of-sight constraints for vehicle-mounted sensors. Even for missions where such

constraints are “mild”, an extensive simulation campaign is required to validate that the 3-DoF trajectories are

executable by a fundamentally 6-DoF lander system.4For the aforementioned future missions where sensing

and guidance are tightly coupled, 3-DoF solutions are likely out of the question without considerable backstage

hand-tuning and edge-case handling eﬀorts. Thus it is well motivated to seek a real-time algorithm for 6-DoF

PDG that does not compromise the beneﬁts of the lossless 3-DoF solution (i.e., speed, guaranteed convergence,

and feasibility) while simultaneously providing the beneﬁt of explicit feasibility with respect to the full 6-DoF

dynamics and coupled guidance-navigation constraints.

Sequential Convex Programming (SCP) emerged as the most natural solution when transitioning from a fully

convex 3-DoF problem to a 6-DoF problem in which some non-convexity is present. As a special case of a

trust region method, SCP iteratively solves a convex approximation of the original optimal control problem, and

updates the approximation as new solutions are obtained.18 This permits the use of “heritage” SOCP solvers

developed for 3-DoF PDG, and the balance of the algorithm design is used to ensure that the SCP iterations

converge to a local optimum of the non-convex 6-DoF problem. In the context of fuel-optimal 6-DoF PDG, SCP

methods have been used to handle: aerodynamic lift and drag; thrust slew-rate constraints;38 free ignition time;

state-triggered constraints that model discrete decisions such as velocity-based angle-of-attack constraints;39 and

compound (i.e., and/or) state-triggered constraints40 such as line of sight constraints that are active only within

pre-speciﬁed slant range bands.41, 42 Collectively, these works show that the constraint satisfaction requirements

of future spaceﬂight missions can be handled via SCP-based 6-DoF PDG algorithms.

Several state-of-the-art SCP algorithms for trajectory generation have emerged in the past 5 years. These

are: Penalized Trust Region (PTR),39, 41 successive convexiﬁcation (SCvx),43–45 TrajOpt,46 GuSTO,47, 48 and

ALTRO.49 The trust region size in PTR is a solution variable whose magnitude is penalized in the cost, whereas

2 of 24

American Institute of Aeronautics and Astronautics

SCvx and GuSTO enforce hard trust regions with outer-loop update schemes. Similar work was done by Liu and

Lu for the speciﬁc case of concave state constraints, albeit with a trust region that is not updated.50 TrajOpt

updates the trust region size, but enforces only soft constraints and no dynamics. ALTRO is a new algorithm that

alternates between augmented Lagrangian iterative LQR to deal with nonlinear dynamics directly, and active-set

projection to satisfy constraints. Beyond these “generalized” solution methods, SCP has been used to solve a

wide range of aerospace guidance problems.51–54 In light of our history as the primary developers of the PTR

method, this paper explores the real-time capability of the PTR method speciﬁcally for PDG.

The real-time capability of the PTR method for other applications has been tested on several occasions. Szmuk

et al. have shown that PTR is able to solve diﬃcult quadrotor path planning problems (including obstacle

avoidance and acrobatic ﬂips) in less than 100 ms running on a 1.7 GHz Intel Atom processor of an embedded

Intel Joule platform.55, 56 More diﬃcult tasks such as ﬂying through hoops and cooperatively transporting a

beam while avoiding obstacles were solved in less than one second.57 Beyond these real-world tests of on-board

PTR, the real-time properties of the method and the eﬀect of discretization were also analyzed in simulation.58, 59

Ultimately, an SCP based method is a sequence of solutions to convex optimization problems and, in the case

of PTR, these problems are SOCPs. In assessing the real-time capability of PTR it is therefore appropriate

to consider existing work on the real-time solution of single-SOCP optimization problems. In the context of

3-DoF PDG, a 7-ﬂight 3-year ﬂight test campaign aboard the Masten Space Systems Xombie sounding rocket

demonstrated that the on-board solution of an SOCP problem is feasible on spaceﬂight processors.60–63 The

tested algorithm, G-FOLD, is based on the theory of lossless convexiﬁcation and was able to compute landing

divert trajectories in 100 ms on a 1.4 GHz Intel Pentium M processor. Moreover, Dueri et al. have shown that the

same algorithm can achieve runtimes of less than 700 ms on the radiation-hardened BAE RAD750 processor.33

The modern paradigm of real-time optimization is to use customized solvers, wherein problem structure is hard-

coded into the solution process by an oﬄine code generator.32, 33, 64 Well-known examples include CVXGEN and

FORCES.65–68 The majority of existing work on real-time optimization is found in the model predictive control

(MPC) literature, where closed-loop feedback is achieved by (generally) calling an optimizer as fast as the desired

execution frequency of the controller. In this context, execution frequencies for linear and quadratic optimization

problems in the kHz-MHz range are possible, and have been applied to electrical drives and an atomic force

microscope.69, 70 MPC has also been used on-board autonomous race cars, achieving re-solve rates of 50 Hz

for miniature cars on an embedded 1.7 GHz ARM A9 chip,71 and 20 Hz for a life-size car on a 2.1 GHz Intel

i7-3612QE.72

MPC strategies have been proposed for 6-DoF PDG.73 However, the MPC paradigm of constantly re-solving an

optimization problem to make feedback control decisions is in conﬂict with the use of classical feedback control

architectures in space missions and can pose constraint feasibility problems. To provide the required 6-DoF PDG

capability while minimally impacting heritage guidance and control architectures, we propose that guidance

algorithms solve for a single, complete, trajectory from the spacecraft’s current state all the way to the landing

site. The vehicle would subsequently track this trajectory using existing feedback control architectures. Given

the real-time capability, new trajectories can be found as-needed (e.g., during landing site re-targeting for hazard

avoidance), but re-solving is not a fundamental requirement of our approach. The objective of “real-time PDG”

is therefore that a single solution for a complete 6-DoF PDG trajectory is computable in a short enough time

span on spaceﬂight hardware so as to be implementable on-board a spacecraft.

A. Primary Contribution

The primary contribution of this paper is to cover the major design aspects of a real-time capable PTR-based

PDG algorithm. We discuss the analytic transformation of the desired optimization problem into a sequence

of standard form SOCP problems, highlighting the inﬂuence of certain parameters and each type of constraint

on the resulting problem size and solution time. We present a hard-coded transcription of the optimization

problem for use with a ﬂight-proven SOCP solver referred to as BSOCP.33 Unlike previous work on the 6-DoF

PDG problem,39–42 we only use static memory allocation, and ensure that our methodology and resulting code

is compatible with common ﬂight code requirements.74 As a numerical demonstration, we use a simpliﬁed in-

plane powered descent problem with independent thrust and torque inputs, for which a theoretically optimal

solution is available.75 The latter qualiﬁcation is key for assessing the optimality that is achieved by our real-

time implementation, and is not available for any other PDG problem that considers the attitude of the vehicle.

Despite having fewer states, the dynamics and constraints of this simpler problem capture important aspects of

the dynamics present in 6-DoF PDG problems. Our secondary contribution is therefore to compare the solution

obtained with the PTR method to this known optimum. This provides valuable insight into the level of sub-

optimality in a PTR-based 6-DoF PDG solution. Our third contribution is to provide detailed timing information

3 of 24

American Institute of Aeronautics and Astronautics

Figure 1: Illustration of the steps in the PTR algorithm. The most time consuming step is highlighted in red

and involves solving a convex SOCP problem.

as a function of the discretization density and a sensitivity analysis for three algorithm metrics as a function of

key design parameters. Our ﬁndings support that the PTR-based 6-DoF PDG algorithm is a real-time capable

algorithm for next generation entry, descent and landing systems.

This paper is organized as follows. First, §II presents the steps to produce an algorithm that is both capable of

solving non-convex optimization problems and is conducive to a real-time implementation. An overview of the

algorithm shows that there are three primary steps: initialization, convexiﬁcation, and the solve step that are

outlined in §II.B, §II.C and §II.D respectively. Next, §III provides a planar landing case study that demonstrates

how the algorithm is constructed using these steps, in addition to the computational and numerical performance

that can be obtained. Lastly, §IV oﬀers concluding remarks.

II. Considerations for Real-Time Implementation of Non-Convex Problems

In this section, we present a general methodology for developing real-time implementations to solve non-convex

optimal control problems of the form:

min

u(·),p φx(tf), p

subject to: ˙x(t) = f(x, u, p),

H0x(t0) = xic, Hfx(tf) = xf,

gi(x, u, p)≤0, i ∈ Ic:={1, . . . ,nc},

(Problem 1)

where x(t)∈Rnxis a continuous-time state vector, u(t)∈Rnuis a continuous-time input vector and p∈Rnpis a

parameter vector. The scalar-valued functions gi:Rnx×Rnu×Rnp→Rrepresent the path constraints imposed

during the maneuver. We assume that the constraints indexed by Icvx ⊆ Icare convex, and the constraints

indexed by Incvx ⊆ Icare non-convex, so that Ic=Icvx ∪ Incvx . The matrices H0and Hfrepresent the ability to

constrain only a subset of the state vector at the initial and ﬁnal time. We assume that f:Rnx×Rnu×Rnp→Rnx

is diﬀerentiable almost everywhere with respect to its arguments. Lastly, we assume without loss of generality

that the cost function is convex and is given in Mayer form76 using the function φ:Rnx×Rnp→R. Any problem

that nominally includes a running cost can be written in this form, and it is the simplest way to transcribe the

continuous time problem into the standard form needed for real-time implementations. Note that free-ﬁnal-time

problems can be expressed in the form of Problem 1 by using the parameter vector p.

A. Successive Convexiﬁcation: Overview

We begin our discussion on real-time solutions to Problem 1 with a high-level overview of the PTR algorithm,

more generally referred to as successive convexiﬁcation.39, 45, 47 Figure 1 illustrates the major steps in the PTR

algorithm. An initialization step is run ﬁrst to deﬁne the initial solution guess (which may be very coarse), set the

scaling matrices to improve the optimization numerical properties, and pre-parse ﬁxed portions of the problem.

§II.B provides details on each of these aspects. Next, the main PTR loop is entered and the initial guess becomes

the ﬁrst reference solution. Throughout the paper, we make reference to “solver” and “PTR” iterations. Their

meaning is highlighted in Figure 1, namely, the former are iterations performed internally by the SOCP solver,

while the latter are the outer iterations around the main PTR loop deﬁned by the convexiﬁcation/test/solve steps.

4 of 24

American Institute of Aeronautics and Astronautics

Algorithm 1 Initilization step.

Input: Current vehicle state and desired terminal boundary conditions.

1: Compute initial guess for states, controls, and parameters using (1).

2: Compute Sx, Su, Spand cx, cu, cpusing (3). Scaling matrices

3: Populate the A, b, c matrices with all constant non-zero entries. Pre-parse step

The convexiﬁcation step returns a convex approximation of Problem 1 about the current reference solution,

wherein the dynamics have been approximated as a discrete linear time-varying system and the non-convex

constraints have been linearized about the reference solution. §II.C provides details on both of these processes.

The output of the convexiﬁcation step allows us to check if the current reference solution satisﬁes the desired

feasibility and convergence requirements. This is done using the stopping criterion explained in §II.E. If passed,

the algorithm terminates. Otherwise, the convex approximation is used to formulate an SOCP in the following

general conic form:

min

zc>z

subject to: Az =b,

z∈ CL× CQ1× · ·· × CQm,

(Problem 2)

where CL={w∈Rl|w≥0}is a linear cone of dimension l, and each CQi={(w0, w)∈Rdi| kwk2≤w0}is a sec-

ond order cone of dimension di. The problem data A∈Rnc×nz,b∈Rncand c∈Rnzare then passed to the solver

to compute a new reference solution. Note that careful parsing is required to express the optimization problem in

the format of Problem 2. All previous work on successive convexiﬁcation, and sequential convex programming in

general, has relied on “modelling” interfaces (often called parsers) that automate the conversion.39,42, 47, 54 How-

ever, these parsers introduce computational overhead, redundant constraints and dynamically allocated memory.

Each of these characteristics are undesirable for real-time spaceﬂight implementations.74 In this work, we oﬀer

a general methodology to “hand parse” the problem and remove these shortcomings by explicitly exploiting

problem structure. Details are given in §II.D.

B. Initialization Step

This section details the initialization steps that are performed prior to calling the main PTR loop. The initializa-

tion step is summarized by Algorithm 1 and consists of three primary operations: generating the initial solution

guess, computing the scaling matrices, and pre-parsing the problem data. These steps can all be done before

calling the main PTR loop shown in Figure 1. If the initialization step is called at some time t<t0, where t0

is the time at which the guidance solution will begin to be executed by the vehicle, the initial state xic must be

projected forward in time by an amount t0−t. The diﬀerence t0−tmust (at least) account for the time spent

computing the guidance solution. For the aforementioned test ﬂights using the 3-DoF G-FOLD algorithm, this

value was been chosen to be one second.77

1. Initial Solution Guess

Using the given initial state of the vehicle, we ﬁrst compute the state solution guess. The simplest way to initialize

the state solution, and the one that is used here, is by using the straight line initialization method.39 We take the

given initial state of the vehicle, xic, and the desired boundary conditions, xf, and compute a linear interpolation

such that

xk,i =N−k

N−1xic,i +k−1

N−1xf,i, i = 1, . . . , nx, k ∈N:={0, . . . , N −1},(1)

where Nis the number of discrete nodes chosen to compute the solution (see §II.C). To initialize the control,

we leverage the known proﬁle of the optimal solution whenever it is available. For the planar landing case study

discussed in §III, the optimal thrust is known to be bang-bang, and so the thrust input is initialized as such,

with switching times guessed based on preliminary ground tests. For the constrained 6-DoF landing problem, the

structure of the optimal thrust remains an open problem, and so we simply initialize with a thrust vector that

opposes gravity. Any torque inputs are generally assumed to be zero. Note that neither the state nor control

guess have to be feasible with respect to the dynamics or constraints. We have observed that diﬀerent initial

guesses can lead the algorithm to converge to diﬀerent solutions,42 and it should be clear that a more accurate

initial guess will result in faster convergence.

5 of 24

American Institute of Aeronautics and Astronautics

With the exception of the ﬁnal time, guesses for the parameter vector will always be application dependent, and

thus no general statements can be made. However, for the ﬁnal time speciﬁcally, we have observed that initializing

the parameter tfto be higher than the expected ﬂight time produces slightly better convergence results. This

is similar to an observation made for the 3-DoF problem in.33 Dueri et al. found that as tfapproached the

minimum feasible time of ﬂight, more solver iterations were required to produce a solution. As tfwas increased,

the solver had an easier time ﬁnding solutions. We have observed a similar trend here for more general landing

problems, and this is discussed more in §III.

2. Scaling Matrices

The scaling of solution variables can be done several ways. There is no general consensus on the best way to scale

optimal control problems to produce numerically well-conditioned parameter optimization problems. While some

authors argue that scaling (and balancing) the continuous time equations of motion is the most appropriate,17,78

others argue that scaling the discrete parameter optimization problem is suﬃcient.79,80 We have found the latter

method to be acceptable in our implementations.42 To this end we deﬁne the following aﬃne transformations

xk=Sxˆxk+cx,(2a)

uk=Suˆuk+cu,(2b)

pk=Spˆpk+cp,(2c)

where the Sx, Su, Spare diagonal matrices of commensurate dimension and cx, cu, cpare vectors that center the

state, control, and parameters. Throughout this paper, scaled quantities are referred to with the ˆ

·adornment.

For the ith component of the state, control and parameter vectors, generically referred to using ai, we can deﬁne

two quantities: (i) the known range of the “true” component’s value [ai,max, ai,min ] and (ii) an interval [ˆalb,ˆaub ]

that we wish to scale each component of quantity ato. Using this information, we use

Sa,ii =ai,max −ai,min

ˆalb −ˆaub

,and ca,i =ai,min −Sa,iiˆalb.(3)

While the interval [ˆalb ,ˆaub] is in theory arbitrary, a judicious choice with respect to generating the standard form

of Problem 2 is to use [ˆalb,ˆaub] = [0,1]. This places the state, control, and parameter vectors into the linear cone

by construction and eliminates the need to enforce the lower bound constraints explicitly. The computational

savings aﬀorded by this choice can be signiﬁcant and are quantiﬁed in Theorem 3.

3. Pre-Parsing

Pre-parsing consists of initializing the matrix A,band cused in Problem 2. There is a signiﬁcant amount of

structure to the non-convex problems that are solved using any successive convexiﬁcation technique, and this

structure is exploited to maximize the speed of the main PTR loop by performing as many computations as

possible during the pre-parse step. For a ﬁxed problem statement, the majority of the non-zero entries in these

containers do not change across the PTR iterations, and the pre-parse step simply populates A, b, c with these

constant non-zero entries.

For this step, an enumeration of the variables and constraints must be decided upon. A generic enumeration of

the variable zand constraints is given in Figure 2. We deﬁne the block v1variables to be all those that appear

in Problem 1 and/or contribute to the nonlinear equations of motion, block v2variables to be all linear slack

variables added to write the problem in standard form, and block v3variables to be those used to form the trust

regionain addition to any Second-Order Cone (SOC) slack variables added to write the problem in standard

form. Similarly, we deﬁne block c1constraints to be those that represent the dynamics and boundary condition

constraints, and deﬁne block c2constraints as all other constraints imposed. These deﬁnitions permit a block

row/column decomposition of the A,band cmatrices that is used to guide the presentation in this paper. For

PTR-type algorithms, the vector ccan be fully populated during the pre-parse step, and only Aand bwill change

across the PTR iterations. All block v2and v3slack variables added to write the convex approximation in the

standard form of Problem 2 will have a corresponding entry in the Amatrix of unit magnitude (±1) that appears

in the row corresponding to the constraint the slack variable was added to. These are represented by the s(for

linear slack variables) and the A

χ(for SOC slack variables) blocks shown in Figure 2. Since all non-zero entries

aThe trust region is often implemented as a second order cone, though this is not necessary. Hence block v3may contain both

linear and second-order cone variables.

6 of 24

American Institute of Aeronautics and Astronautics

z=

ˆx

ˆu

ˆp

ν+

ν−

s1

s2

.

.

.

sml

χη,p

χη

.

.

.

χmq

block v1

block v2

block v3

φ

0

φ

0

0

wvc1

0

.

.

.

0

wtr,p c

χ

wtr c

χ

.

.

.

0

=c

A="A

P0 0

A

CsA

χ#

block v1

block v2

block v3

block c1

block c2"b

P

b

C#=b

·

P: computed during pre-parse & propagation

·

C: computed during pre-parse & constraint linearization

s: fully pre-parsed

·

χ: fully pre-parsed

φ: fully pre-parsed

Figure 2: Generic enumeration of the variables and constraints for the standard form of a trajectory optimization

problem. The constraint block c1corresponds to the dynamics and boundary conditions, while constraint block c2

corresponds to all path constraints enforced as inequalities. Block v1variables are used either directly in Problem 1

or to impose the dynamics and boundary conditions. Block v2variables represent linear slack variables of arbitrary

dimension, and there are mlsuch variables. Block v3variables represent the trust region implementation and

SOC variables of arbitrary dimension, and there are mqsuch variables.

are ±1, and occur in user-speciﬁed rows and columns, the entire sand A

χblocks can be populated during the

pre-parse step and do not change throughout the iterations.

The ·

Pblocks correspond to the equations of motion and boundary conditions, and can be partially populated

during the pre-parsing step. The remaining portions can only be populated after the convexiﬁcation step. The

·

Cblocks corresponds to the path constraints enforced as inequality constraints. These blocks can also only be

partially populated during the pre-parse step, and the remaining portions added only after the convexiﬁcation

step. The degree to which the ·

Pand ·

Cblocks can be pre-populated is application dependent and will vary.

C. Convexiﬁcation Step

The convexiﬁcation step is responsible for computing a convex approximation to the nonlinear equations of motion

and all non-convex constraints gifor i∈ Incvx. This is achieved using two separate steps that can be performed

in parallel: propagation and constraint linearization. Note that in implementation, all matrix computations

are performed using 1D “ﬂat” arrays. This avoids both the use of 3D arrays to provide a temporal index, and

maintaining large 2D arrays that contain mostly zeros.59

1. Propagation

To enforce the dynamic equations of motion as a set of convex equality constraints, they must be mapped to

discrete-time aﬃne functions of the state, control, and parameters. The technique to do this has been outlined

previously in39, 42, 59 and so only the key steps required to discuss the implications for real-time implementation

are included here. An archetypal algorithm is given in Algorithm 2 to provide an outline of the steps. Using the

current reference solution, the nonlinear dynamics are ﬁrst normalized with respect to time, and then expanded

in a ﬁrst order Taylor series about the reference triplet {¯x(t),¯u(t),¯p}to yield:

˙x(τ) = A(τ)x(τ) + B(τ)u(τ) + S(τ)p+R(τ),(4)

where τ∈[0,1] is a normalized time variable and A(τ), B(τ), S(τ) are the partial derivatives of fwith respect

to state, control, and the parameters respectively evaluated along the reference trajectory. Based on the results

presented in,59 we recommend using an aﬃne interpolation of the control to discretize (4). To do so, we select

7 of 24

American Institute of Aeronautics and Astronautics

Ntime nodes between the current initial and ﬁnal times

t0=t0< t1<· · · < tN−1

| {z }

real time nodes

=tf≡0 = τ0< τ1<· · · < τN−1

| {z }

propagation time nodes

= 1.(5)

The temporal nodes do not need to be distributed equally between their end points. We now use the discrete

variable k∈N:={0, . . . , N −1}to index the state and control vectors. The control vector is assumed to vary

linearly between the values of ukand uk+1 at each node k∈Nproducing the relation

u(τ) = λ−

kuk+λ+

kuk+1, τ ∈[τk, τk+1 ],(6)

where λ−

k=τk+1−τ/τk+1−τkand λ+

k= 1 −λ−

k. The exact discretization of (4) can then be computed as

xk+1 =Akxk+B−

kuk+B+

kuk+1 +Skp+Rk, k ∈ {0, . . . , N −2},(7)

where for each k∈ {0, . . . , N −2},

Ak:= Φ(τk+1, τk),(8a)

B−

k:=AkZτk+1

τk

Φ−1(τ, τk)λ−

k(τ)B(τ)dτ, (8b)

B+

k:=AkZτk+1

τk

Φ−1(τ, τk)λ+

k(τ)B(τ)dτ, (8c)

Sk:=AkZτk+1

τk

Φ−1(τ, τk)S(τ)dτ, (8d)

Rk:=AkZτk+1

τk

Φ−1(τ, τk)R(τ)dτ. (8e)

where Φ(τ, τk) is the zero input state transition matrix for the linear time varying system (4).

In implementation, we must compute N−2 sets of the matrices given in (8). Each set of matrices is computed

by numerically integrating the integrands in (8) along with the state vector. We use a ﬁxed-step RK4 integration

routine, with Nsub points. A ﬂat 1D array of dimension nx(nx+ 2nu+ 3) is needed for this operation. For each

k= 0, . . . , N −2 we integrate the following diﬀerential equation over the interval [τk, τk+1] using Nsub nodes

˙

P(τ) =

f(Px(τ),¯u(τ),¯p)

A(τ)PΦ(τ)

PΦ(τ)−1λ−

k(τ)B(τ)

PΦ(τ)−1λ+

k(τ)B(τ)

PΦ(τ)−1S(τ)

PΦ(τ)−1R(τ)

, P (τk) =

¯xk

ﬂat (Inx)

0nxnu×1

0nxnu×1

0nx×1

0nx×1

,where P(τ) =

Px(τ)

PΦ(τ)

PB−(τ)

PB+(τ)

PS(τ)

PR(τ).

.(9)

Here, the ﬂat (·) operation maps a 2D array to a 1D array using a column major representationb. Note that

the initial condition P(τk) is reset at each iteration to the value of the reference state trajectory at the kth

node. The beneﬁts of this resetting strategy are signiﬁcant and have been discussed in previous work.39, 42, 59

The derivative in (9) must be evaluated four times per subinterval, for a total of 4Nsub times per propagation

step. Our results suggest that the PTR algorithm’s convergence behaviour and quality of the ﬁnal solution is

not strongly dependent on the choice of Nsub, and a value of Nsub ∈[5,15] is typically suﬃcient for rigid body

PDG dynamics. To obtain the ﬁnal values of the matrices in (8), we must multiply each of PB−(τk+1) through

PR(τk+1) by the value of PΦ(τk+1). The ﬁnal matrices in (8) can either be stored as “ﬂattened” vectors in an

output data structure or placed directly into the Aand bmatrices used to construct the standard form SOCP.

Computing the Matrix Inverse One of the key steps that drives the computational complexity of the

propagation step is the matrix inverse required to evaluate the derivative of PΦ(τ) in (9). It is customary

to use Gaussian elimination with partial pivoting to compute this inverse.81 This involves computing an LU

decomposition and inverting the two factors. For powered descent problems that use Cartesian variables to

represent the state vector and have the mass variable in the ﬁrst position, we have observed that the entries

bIn the code, no explicit conversions between 1D and 2D arrays are needed, and so the use of column major representation is not

in conﬂict with the C/C++ row major array storage.

8 of 24

American Institute of Aeronautics and Astronautics

below the diagonal in PΦ(τ) do not exceed 1 under the condition that the ratio Γ(τ)

/m(τ)2<1, where Γ(τ) is the

thrust magnitude and m(τ) is the vehicle mass. Moreover, the equations of motion imply that the (1,1) entry in

PΦ(τ) is constant and equal to 1. This means that partial pivoting may not be theoretically necessary to ensure

numeric stability in this case. However, for powered descent problems stated using dual quaternions the same

statement does not hold,42 and partial pivoting must be retained in this case. To maintain a general solution

method, we therefore retain partial pivoting in our implementations.

Computational Complexity For each k= 0, . . . , N −2, the propagation step can be performed in

O4Nsub 5

3n3

x+ 2n2

xnu+ 6n2

x

ﬂoating point operations. Powered descent problems typically have nx∈[7,15] and nu∈[2,6]. As demonstrated

in §III, the propagation step can be performed in a near-negligible amount of time if it is implemented properly.

Measuring Dynamic Feasibility One of the advantages of the propagation step is the ability to estimate

the dynamic feasibility of the current reference solution {¯xk,¯uk,¯p}k∈N. What we mean by this is that, given

the nonlinear dynamics of Problem 1, if the discrete control and parameter solution {¯uk,¯p}k∈Nare used to

integrate the nonlinear equations of motion using the interpolation scheme (6), then the resulting (open-loop)

state will pass through the discrete points {¯xk}k∈Nto within some user deﬁned tolerance. This notion of dynamic

feasibility, coupled with an analogous measure of feasibility with respect to the constraints, provides a simple

measure of the quality of a solution before it is executed.

To measure dynamic feasibility, we leverage the availability of the propagated state Px(τk+1). Ideally, this

vector would match the value predicted by the reference trajectory, ¯xk+1. We compute the defect at the (k+1)th

node using

∆k+1 =kPx(τk+1)−¯xk+1k2.(10)

If each ∆k+1 is less than a prescribed tolerance feasible, then we say that the reference trajectory is dynamically

feasible. Typically, choosing feasible ≤10−2provides acceptable results, but this value is dependent on the

function fthat describes the dynamic equations of motion.

2. Constraint Linearization

The next part of the convexiﬁcation step is to compute a linear approximation to all non-convex path constraints.

These are constraints of the form

gi(x, u, p)≤0, i ∈ Incvx,(11)

for some functions githat are diﬀerentiable almost everywhere. This step is performed as part of the con-

vexiﬁcation step so that it always precedes the parsing step discussed in §II.D. Using the reference trajectory

{¯xk,¯uk,¯p}k∈Nwe compute the linearization of (11) to be

gi(¯xk,¯uk,¯p) + ∇gi¯xk,¯uk,¯p>

xk−¯xk

uk−¯uk

p−¯p

≤0, k ∈N,(12)

where ∇gi¯xk,¯uk,¯p∈R(nx+nu+np)×1is gradient of gievaluated at the kth reference node. Each non-convex

constraint is then approximated by Nlinear inequalities. Note that similar to the storage of output.Adin the

propagation step of Algorithm 2, we store the data for the linear approximation of the ith non-convex constraint

in a single 2D array where the ﬁrst entry in the kth column is the value of

gi(¯xk,¯uk,¯p)− ∇gi¯xk,¯uk,¯p>

¯xk

¯uk

¯p

,(13)

and the remaining rows are used to store the value of the gradient ∇gievaluated at the reference solution’s kth

node. Note that if a constraint giaﬀects only a subset of state, control, or parameter, then the size of this 2D

array is shrunk accordingly.

As gi(¯xk,¯uk,¯p) is computed for each i∈ Incvx and k∈N, the feasibility with respect to each constraint at the

solution nodes can be checked. If any constraints are found to be violated, then the value of output.feasible

9 of 24

American Institute of Aeronautics and Astronautics

Algorithm 2 The convexiﬁcation step. All matrix operations are performed as 1D array operations.

Input: Reference trajectory {¯xk,¯uk,¯p}for k∈Nand feasiblity tolerance feasible.

Output: Data structure, output, containing the discretized dynamics matrices, linearized constraint data, and

feasibility indicator.

1: function convexify

2: Set output.feasible = true

3: Call the propagate function

4: Call the linearize function

5: end function

6: function propagate

7: ˆ

P0←ﬂat (Inx) 01×nxnu01×nxnu01×nx01×nx>.

8: for k= 0, . . . , N −2do

9: P←¯x>

kˆ

P0>reset using reference state, not using the previous Px

10: h←τk+1−τk/Nsub−1the rk4 step size using Nsub steps

11: Call rk4 on the derivs function to update P

12: Compute the defect ∆k+1 using (10)

13: if ∆k+1 > feasible then

14: output.feasible = false

15: end if

16: Set outputs:

17: output.Ad[:][k]←PΦ[:] means “all rows”

18: output.Bd,−[:][k]←PΦPB−

19: output.Bd,+[:][k]←PΦPB+

20: output.S[:][k]←PΦPS

21: output.R[:][k]←PΦPR

22: end for

23: end function

24: function linearize

25: for i∈ Incvx do

26: for k= 0, . . . , N −1do

27: output.Gi[1:][k]← ∇gi¯xk,¯uk,¯p[1:] means “all rows starting from 1”

28: output.Gi[0][k]←gi¯xk,¯uk,¯p− ∇gi¯xk,¯uk,¯p>¯x>

k,¯u>

k,¯p>>

29: if gi¯xk,¯uk,¯p> feasible then

30: output.feasible = false

31: end if

32: end for

33: end for

34: end function

35: function derivs(τ, P )

36: Compute Ψ ←P−1

Φusing an LU decomposition with partial pivoting

37: Compute λ−

k(τ) and λ+

k(τ) and interpolate u(τ) using (6)

38: Compute partials:

39: f←f(Px, u(τ),¯p)

40: A← ∇xfPx, u(τ),¯p

41: B← ∇ufPx, u(τ),¯p

42: S← ∇pfPx, u(τ),¯p

43: R← −APx−Bu(τ)

44: Set outputs:

45: ˙

Px←f

46: ˙

PΦ←APΦ

47: ˙

PB−←Ψλ−

k(τ)B

48: ˙

PB+←Ψλ+

k(τ)B

49: ˙

PS←ΨS

50: ˙

PR←ΨR

51: end function

10 of 24

American Institute of Aeronautics and Astronautics

is set to false. If no constraints are violated, this does not necessarily imply that the trajectory will satisfy

the constraints at times between the solution nodes, a phenomenon referred to as clipping. This is therefore a

necessary but not suﬃcient assessment of feasibility with respect to path constraints. In contrast, the previously

deﬁned assessment of dynamic feasibility is both necessary and suﬃcient.

D. Solve Step

The convexiﬁcation step computes all of the data that is needed to formulate a convex approximation to Problem

1 and to obtain a new reference solution. Prior to calling the solver, the remaining data that was not placed in A

and bduring the pre-parsing step must be added, a function that we refer to as parsing. Upon completion of the

parsing step, we have fully deﬁned a problem in the format of Problem 2, and the solver is then called. The PTR

method solves each convex approximation to full optimality, rather than settling for a sub-optimal solution and

iterating again. Since calling the solver tends to dominate the algorithm runtime (even for a small number of

solver iterations), reducing the number of calls to the solver is paramount to obtaining fast guidance trajectories.

1. Parsing

The parsing step adds the data from the convexiﬁcation step to Aand b. These data form the remaining portions

of ·

Pand ·

Cblocks shown in Figure 2. Since the standard form solution vector zcontains the scaled state,

control and parameters as 1D stacked vectors, the discretized dynamics (7) are written in block form as

ˆ

R=ˆ

Aˆx+ˆ

Bˆu+ˆ

Sˆp+ν+−ν−,(14)

where ν=ν+−ν−is a virtual control term expressed using two variables in the linear cone39, 43–45 and

ˆ

A=

A0Sx−Sx0· · · 0

0A1Sx−Sx· · · 0

.......

.

.

0 0 0 AN−2Sx−Sx

,(15a)

ˆ

B=

B−

0SuB+

0Su0· · · 0

0B−

1SuB+

1Su· · · 0

.......

.

.

0 0 0 B−

N−2SuB+

N−2Su

,(15b)

ˆ

S=

S0Sp

S1Sp

.

.

.

SN−2Sp

,(15c)

ˆ

R=

cx−R0−A0cx−B−

0cu−B+

0cu−S0cp

.

.

.

cx−RN−2−AN−2cx−B−

N−2cu−B+

N−2cu−SN−2cp

.(15d)

If H0∈Rn0×nxand Hf∈Rnf×nxare the matrices in Problem 1 corresponding to the boundary conditions,

the Pblock can then be ﬁlled in as

A

P=

hH0Sx0n0×nx(N−1)i0n0×nuN0n0×np0n0×nxN0n0×nxN

ˆ

Aˆ

Bˆ

S InxN−InxN

h0nf×nx(N−1) HfSxi0nf×nuN0nf×np0nf×nxN0nf×nxN

b

P=

x0−Hocx

ˆ

R

xf−Hfcx

.(16)

The entries in (15) and (16) that are independent of the matrices computed in (8) will have been populated

during the pre-parse step outlined in §II.B.3.

Remark 1 The notation adopted in some previous work has used an identity block in the upper left corner of

the ˆ

Amatrix in (15a).59 Including this block in addition to the initial condition can create an Amatrix that does

not have full row rank and lead to potential numerical issues in the solver.

11 of 24

American Institute of Aeronautics and Astronautics

While every trajectory optimization problem will have the same basic structure for the ·

Pblocks, the ·

Cblocks

are heavily application dependent. A trajectory optimization problem stated with two diﬀerent sets of constraints

will have the same ·

Pblocks, but will have diﬀerent ·

Cblocks. As such, we shall only treat two generic classes of

path constraints here: convex linear or second-order cone constraints and general non-convex constraints. Since

the non-convex constraints are simply linearized, they are eﬀectively the same as the linear constraints. Hence

we need only consider linear constraints and second-order cone constraints.

Linear Constraints There are several linear constraints that will form part of all successive convexiﬁcation

algorithms. For example, the use of 1-norm penalty functions for the virtual control and box-type constraints

on the state, control, and parameter vectors each produce linear constraints. In addition, there may be several

other linear constraints that arise either directly in Problem 1 or from linearizing non-convex constraints. To

illustrate how these are parsed, consider a linear state constraint of the form g>

kˆxk≤hkfor each k∈Nand some

gk∈Rnxand hk∈R. This constraint is rewritten in standard form by introducing the slack variable s∈RN

+

and writing

G>ˆx+s=h, s ≥0,(17)

where

G:=

g>

00· · · 0

0g>

1· · · 0

....

.

.

0 0 · · · g>

N−1

∈RN×nxNand h:=

h0

h1

.

.

.

hN−1

∈RN.(18)

The matrix Gis then added to the A

Cblock in the appropriate location based on the deﬁnition of block v1in z

and block c2in A(see Figure 2). Similarly, his added to b

Cin the corresponding rows of block c2. The same

procedure applies to linear control and parameter constraints.

Remark 2 If the linear constraint comes from a non-convex path constraint, then Gand hwill in general be

functions of the reference trajectory {¯xk,¯uk,¯p}k∈N, and must be re-evaluated during each convexiﬁcation step

when a new reference is available. The same can be true even for constraints that are linear in their original form

in Problem 1. As an example of the latter, consider a trust region imposed using the ∞-norm, which is equivalent

to two linear constraints on each of the state, control, and parameter vectors. For each linear constraint, hmust

be re-evaluated at each PTR iteration as the reference solution changes.

Theorem 3 To impose a linear path constraint on the state or control in Problem 1 requires adding Nslack

variables to Problem 2 and adding Nrows to both Aand b.

As mentioned in §II.B.2, the state, control, and parameter vectors are scaled so that the variables being solved

for are already in the linear cone R+. Hence no additional constraints are needed to enforce the scaled variable’s

lower bound. Rather, they are enforced implicitly by the solver. Theorem 3 tells us that scaling the solution

vectors in this way saves us nxNslack variables and nxNrows in the matrices Aand b. Even for the simplest

powered descent guidance problems, which have nx= 7, this represents a savings of at least 70 variables and

rows of Aand bfor typical implementations.

Second-Order Cone Constraints Not all successive convexiﬁcation algorithms designed for trajectory op-

timization will make use of second order cone constraints. For powered descent problems speciﬁcally, however,

there are several constraints that are naturally expressed in this form, such as an upper bound on thrust mag-

nitude, thrust pointing constraints, approach cone constraints, and more. The ability to obtain trajectories

that explicitly enforce such constraints is important for spaceﬂight applications. Moreover, we have found that

2-norm-based trust regions are an eﬃcient method to guide the convergence process for the PTR algorithm. To

illustrate how these constraints are handled during the parsing step, consider a generic second order cone path

constraint imposed on the state vector of the form kSqˆxk+cqk2≤g>

qˆxk+hq, for some Sq∈Rd×nx,cq∈Rd,

gq∈Rnxand hq∈Rand each k∈N. Note that for the trajectory optimization problems considered here, it is

rare for the data describing a second order cone constraint to vary in time (i.e., change with k). This constraint

is rewritten in standard form by introducing three slack variables µk∈Rd, σk∈R+and sk∈R+for each k∈N

and writing

µk=Sqˆxk+cq, σk+sk=g>

qˆxk+hq⇒"σk

µk#∈ CQd+1 .(19)

12 of 24

American Institute of Aeronautics and Astronautics

Algorithm 3 The solve step.

Input: Matrices A, b, c and the output data structure of the convexiﬁcation step.

Output: The data structure output with the reference trajectory overwritten.

1: function solve socp

2: Call parse to update A, b, c

3: z∗=bsocp(A, b, c)Call solver BSOCP with pre-deﬁned tolerance values

4: Compute output.delta x using (21)

5: Set outputs: ˆx∗,ˆu∗,ˆp∗are retrieved from z∗.

6: output.x = (IN⊗Sx)ˆx∗+ (1N⊗cx)

7: output.u = (IN⊗Su)ˆu∗+ (1N⊗cu)

8: output.p =Spˆp∗+cp

9: end function

The expressions in (19) now form two linear constraints, and can be written in standard form as follows. First,

deﬁne a vector χ:=σ0µ>

0σ1µ>

1· · · σN−1µ>

N−1>∈RN(d+1). Then,

−IN⊗Sqˆx+IN⊗[0 Id]χ=1N⊗cqand −IN⊗gqˆx+IN⊗[1 01×d]χ+INs=hq1N(20)

where ⊗is the Kronecker product, are equivalent to (19) with the additional distinction that each pair (σk, µk)∈

CQd+1 .

Remark 4 The representation of the SOC constraint (20) can be entirely added to the matrices Aand bduring

the pre-parse step, unless it represents a trust region constraint. For a trust region constraint stated as an SOC

constraint, the matrices Sq, gq, hqare constant and may be pre-parsed, while cqchanges across the iterations and

is part of the b

Cblock.

Theorem 5 To impose a d+ 1 dimensional second order cone path constraint in Problem 1 requires adding at

most N(d+ 2) variables to Problem 2 and an additional N(d+ 1) rows to both Aand b.

The at most qualiﬁer in Theorem 5 is due to the structure of variable-width trust regions in PTR methods,

where the right hand side of the SOC path constraint is already a solution variable and an additional slack

variable does not need to be added to the problem. Contrasting Theorem 5 with Theorem 3 allows us to quantify

the possible diﬀerence in problem size available by replacing second order cone variables with linear variables

and vice versa.

2. Calling the Solver

After the parsing step, the data A, b, c are passed to the BSOCP solver that in turn provides an optimal solution, see

Algorithm 3. The BSOCP solver uses interior point methods, is written in C, and was designed with the express

goal of solving powered descent guidance algorithms for ﬂight implementations. All technical details relating

to the solver are summarized in64 and we do not attempt to cover them here. The solver’s capabilities were

demonstrated during the aforementioned G-FOLD ﬂight test campaign as part of the Autonomous Ascent and

Descent Powered-Flight Testbed (ADAPT) project led by NASA’s Jet Propulsion Laboratory in collaboration

with Masten Space Systems.61–63, 77

The solver is called by passing a data structure that contains A, b and c, along with the sizes of each cone

CL× CQ1× · ·· × CQmqand the numbers l, mq, where lis the dimension of the cone CL. The parameters used to

deﬁne numerical tolerances and convergence, listed in [64, Table A.1], must be tailored to the speciﬁc problem

instance being implemented. If z∗is the solution returned by the solver, we note that not all of z∗needs to

be retained. The new reference trajectory {¯xk,¯uk,¯p}k∈Ncan be extracted by unscaling the entries of z∗that

correspond to ˆx, ˆu, ˆp. Prior to terminating the solve step, we leverage the fact that the scaled state vector ˆxis

already available on the stack and compute the maximum temporal diﬀerence for later use:

δx:= max

k∈Nkˆxk−S−1

x(¯xk−cx)k∞.(21)

13 of 24

American Institute of Aeronautics and Astronautics

Table 1: Possible exit conditions for the successive convexiﬁcation algorithm.

Converged Feasible Description

3 3 Converged and feasible.

73Reached maximum PTR iterations before δx< solve.Safe but sub-optimal.

37Converged but not feasible. Do not use.

7 7 Not converged and not feasible. Do not use.

E. Stopping Criteria

The ﬁnal component of the algorithm is the stopping criteria, shown as the “Test” block in Figure 1. The possible

exit conditions are given in Table 1. As noted in42 we have found for powered descent problems that relatively

large changes in the control variables (in particular the thrust) can have little impact on the state variables.

Moreover, since the cost function is assumed to be in Mayer form, small changes to the state vector imply small

changes in the optimal cost. The converse is not necessarily true, and therefore we use a state-based convergence

tolerance that is based on δxcomputed in (21). Once δx< solve, the iterations are terminated provided that

output.feasible is true. Note that a trajectory cannot be dynamically feasible unless the virtual control norm is

small enough to allow this, and hence checking output.feasible is a more robust exit criterion than checking the

norm of the virtual control, since it also includes checking the feasibility with respect to non-convex constraints

at each temporal node.

III. Case Study: Planar Landing Problem

To illustrate the design methodology for real-time implementable algorithms, we present a case study of the

fuel-optimal planar landing problem introduced in.75 This problem has nonlinear dynamics that serve as the

sole source of non-convexity in the problem. While non-convex constraints can be added and the design process

remains unchanged, we retain the convex state and control constraints for this case study so that we may compare

our results to the analytically optimal solution structure proven in.75 Planar landing problems have nx= 7

states, nu= 2 controls and np= 1 parameter (the ﬁnal time) for which to solve. The state vector, x(t)∈Rnx,

is comprised of the mass, m(t)∈R++, the inertial position rI(t)∈R2, the inertial velocity, vI(t)∈R2, a single

attitude variable θ(t)∈Rand the angular velocity ω(t)∈R. The control, u(t)∈Rnu, is assumed to come from a

body-ﬁxed rocket engine capable of generating variable thrust Γ(t)∈R++ and a separate actuation mechanism

capable of independently providing a torque τ(t)∈R(e.g., an RCS system, grid ﬁns, etc.). The equations of

motion are given for t∈[t0, tf] by

˙m(t) = −αΓ(t),˙rI(t) = vI(t),˙vI(t) = Γ(t)

m(t)d(t) + gI,˙

θ(t) = ω(t),˙ω(t) = τ(t)

J,(22)

where αis the reciprocal of the eﬀective exhaust velocity, d(t):=−sin θ(t) cos θ(t)>,gIis the constant inertial

gravitational acceleration, and Jis the constant inertia about the body axis orthogonal to the landing plane.

The initial and ﬁnal states are constrained according to

H0x(t0) =

1000000

0100000

0010000

0001000

0000100

0000001

x(t0) =

mic

rI,ic

vI,ic

ωic

, Hfx(tf) =

0100000

0010000

0001000

0000100

0000010

0000001

x(tf) =

rI,f

vI,f

θf

ωf

(23)

where xic ∈Rn0and xf∈Rnfrepresent the right hand sides of the prescribed boundary conditions.

For this problem, since the control inputs are scalar and decoupled, we formulate bounds on their magnitude

as the box constraints

umin ≤u(t)≤umax ≡

Γmin ≤Γ(t)≤Γmax,

−τmax ≤τ(t)≤τmax.(24)

14 of 24

American Institute of Aeronautics and Astronautics

FI

zI

yI

FB

Γ

θ

τ

gI

FI

zI

yI

xI

vI

−rI

gI

Figure 3: A depiction of the planar landing scenario used for the real-time powered descent guidance case study.

where Γmin,Γmax , τmax ∈R++. For numerical solutions, we bound the state variables using

xmin ≤x(t)≤xmax,(25)

for some xmin, xmax ∈Rnx. In this case study, we take xmin and xmax to be just large enough so that none of

the bounds are active during the descent, thereby using their numerical values for scaling purposes only.

The minimum fuel cost function can be expressed in Mayer form by using the ﬁnal mass of the vehicle. Max-

imizing the ﬁnal mass is equivalent to minimizing the fuel consumed, and so we take >x(tf):=−m(tf) as the

cost. The continuous time optimal control problem that we wish to solve is given by

min

tf, u(·)>x(tf)

subject to: ˙x=f(x, u, tf),(22)

H0x(t0) = xic Hfx(tf) = xf,(23)

umin ≤u(t)≤umax,(24)

xmin ≤x(t)≤xmax.(25)

(Problem 3)

Following the procedures discussed in §II and,39, 41 for each PTR iteration we solve the convex approximation

given by Problem 4, posed for clarity using unscaled variables. This case study uses Nequally spaced temporal

nodes. Note that we elect to use a 2-norm trust region that requires the use of several SOC variables. Use of

a diﬀerent norm, such as the inﬁnity norm, would in contrast allow the trust region to be written using only

linear constraints. However, Theorems 3 and 5 indicate that using the inﬁnity norm trust region in place of the

2-norm trust region would in fact require N(nx+nu−1) additional variables and N(nx+nu) additional rows

in the Aand bmatrices. Empirical results for this particular problem reveal that this increase in problem size

has a signiﬁcant impact on the resulting solve times, even though the use of linear trust regions leads to a linear

program. Over 100 trials using both methods on the exact same problem, the 2-norm trust region provided an

average decrease of 11 ms in solver time per PTR iteration compared to the inﬁnity norm trust region. This

speed-up may be speciﬁc to this particular problem. As such, we proceed by using the 2-norm trust region on

15 of 24

American Institute of Aeronautics and Astronautics

both the state and control.

min

x,u,p,ν,η,ηp

>xN−1+wvckνk1+wtr1>

Nη+wtr,pηp

subject to: H0x0=xic,

xk+1 =Akxk+B−

kuk+B+

kuk+1 +Skp+Rk+νk, k = 0, . . . , N −2

HfxN−1=xf,

xmin ≤xk≤xmax, k = 0, . . . , N −1

umin ≤uk≤umax, k = 0, . . . , N −1

pmin ≤p≤pmax,

|p−¯p| ≤ ηp,

kxk−¯xkk2+kuk−¯ukk2≤ηk, k = 0, . . . , N −1.

(Problem 4)

We then scale the solution variables in Problem 4 by substituting xk←Sxˆxk+cx,uk←Suˆuk+cuand

p←Spˆp+cpwherever they appear, except in the trust regions. Following [41, Remark IV.1], we scale the trust

region constraints using

|ˆp−S−1

p(¯p−cp)| ≤ ηp,(26a)

kˆxk−S−1

x(¯xk−cx)k2+kˆuk−S−1

u(¯uk−cu)k2≤ηk, k = 0, . . . , N −1.(26b)

Next, we introduce slack variables so that all problem variables reside either in a linear cone or in a second-order

cone, and all constraints are expressed as equalities. This follows the general procedures outlined in §II.D.1. Note

that slack variables are also introduced to express the cost function as a linear function of the solution variables

using equivalent problem transformations.20 Each of these steps are straightforward, except the implementation

of the 2-norm trust region, which we highlight here. The state and control trust region is implemented by

introducing Nvariables (ηx,k, µx,k) and (ηu,k, µu,k ) such that

µx,k = ˆxk−S−1

x(¯xk−cx) and µu,k = ˆuk−S−1

u(¯uk−cu),(27)

whereby kµx,kk2≤ηx,k and kµu,k k2≤ηu,k are now equivalent to (26b). Note that since ηx,k and ηu,k are solution

variables, we do not need to add another slack variable to this formulation as in (19). We can reconstruct the

original trust region ηkif needed as ηk=ηx,k +ηu,k. Deﬁne then the two variables

χx:=

ηx,0

µx,0

.

.

.

ηx,N−1

µx,N−1

∈RN(nx+1),and χu:=

ηu,0

µu,0

.

.

.

ηu,N−1

µu,N−1

∈RN(nu+1).(28)

The trust region constraint (26) can then be expressed as

ˆp−ηp+sp=bp,ˆp+ηp−s0

p=bp,(29a)

ˆx+Hµ,xχx=bx, Hµ,x :=IN⊗0nx×1−Inx,(29b)

ˆu+Hµ,uχu=bu, Hµ,u :=IN⊗0nu×1−Inu.(29c)

where, sp, s0

p∈R+, (ηx,k, µx,k )∈ CQnx+1 and (ηu,k , µu,k )∈ CQnu+1 for each k∈Nand

bx=

S−1

x(¯x0−cx)

.

.

.

S−1

x(¯xN−1−cx)

, bu=

S−1

u(¯u0−cu)

.

.

.

S−1

u(¯uN−1−cu)

,and bp=S−1

p(¯p−cp).(30)

Note that since there is only a single parameter in this problem, the trust region |ˆp−bp| ≤ ηpis simply a linear

constraint and both ˆpand ηpremain in the linear cone.

To write the convex Problem 4 in standard form, we follow Figure 2 to order the solution variables using the

block v1, v2and v3structure. Recall that block v1contains all variables used to write the (nonlinear) equations

16 of 24

American Institute of Aeronautics and Astronautics

"H0Sx0

ˆ

A# "0

ˆ

B# "0

ˆ

S#INx−INx

h0HfSxiINx−INx−INxINx

INx−INxINx−INx

INxINx

INuINu

1 1

1 1 −1

1−1 1

INxHµ,x

INuHµ,u

A"xic −H0cx

ˆ

R#

hxf−Hfcxi

0

0

1Nx

1Nu

1

bp

bp

bx

bu

b

h0>i0 0 0 0 wvc1>

Nx0000000wtr,p wtrH>

η,x wtrH>

η,u

cData that

changes each

iteration

Nx:=nxN

Nu:=nuN

Figure 4: The A, b and cmatrices for the planar landing case study. All empty blocks are zero, and the data

that is not pre-parsed are highlighted by blue boxes.

of motion, block v2contains the linear slack variables added to write the problem in standard form, and block

v3contains all variables relating to the trust region implementations and all SOC variables. The A,band c

matrices can then be written as shown in Figure 4, with the block structure indicated by the gray lines. Note

that in Figure 4 we have deﬁned

Hη,x :=1N⊗1 01×nxand Hη,u :=1N⊗1 01×nu.(31)

The problem dimensions can be computed as a function of the base units N, nx, nuand npto be:

Variables: N(8nx+ 3nu+ 2) + 5np,

Equality constraints: N(5nx+ 2nu)+3np+ (nx−1),

Linear cones: N(7nx+ 2nu)+5np,

Second order cones: 2N.

A. Initialization Step

Using (1), the initial guess was computed by linearly interpolating between the vector mic r>

I,ic v>

I,ic 0ωic>

and the vector mfr>

I,f v>

I,f θfωf>where mf=mic+mmin

2. Given that the optimal thrust solution is always on

the boundary of the interval (24),75 we initialize the thrust input channel using

Γk=

Γmin, k = 0,1, . . . , m

Γmax, k =m+ 1, . . . , N. (32)

The eﬀect of the parameter mon the computed solution for a ﬁxed Nis studied in Figure 8. The optimal torque

input does not necessarily activate either of its constraints (24), and so we initialize the torque to be zero at each

temporal node.

The pre-parse step was implemented after writing down the matrices in Figure 4. Each non-zero entry that

is not encompassed by a blue box was set during the pre-parse step of the initialization function, along with a

17 of 24

American Institute of Aeronautics and Astronautics

Table 2: Percentage of the data deﬁned during the pre-parse step for Problem 4 for a discretization density of

N= 20. Note that Ais 99.7% sparse.

Total Size Non-Zero Entries Deﬁned at Pre-parse Pct. %

A 789 ×1285 2919 2410 73.3

b 789 506 193 38.1

c 1285 182 182 100

Table 3: Nominal parameters used in the planar landing case study.

Parameter Value Units Parameter Value Units

tf,guess 8.0 s tf,max /min 4.0/12.0 s

mic 5.0 kg mmin 2.0 kg

rI,ic [6.0 24.0]>mrI,f [0 0]>m

vI,ic [−4.0−2.0]>m/svI,f [0 0]>m/s

ωic 0 rad/sωf0 rad/s

θ0∈[−π, π] rad θf0 rad

Γmin 1.5 N Γmax 6.5 N

τmax 0.1 Nm J0.5 kg m2

Isp 3 s−1g−1 m/s2

wvc 102−wtr 5−2−

wtr,p 10−2−Nsub 15 −

feasible 10−2−solve 10−3−

subset of the data within the blue boxes. With regards to the planar landing problem considered here, Table 2

indicates the number of non-zero entries that can be populated at this time. Decoupling the pre-parse and parse

steps allows signiﬁcant computational savings, since only about 800 non-zero values need to be updated during

each SCP iteration of the successive convexiﬁcation algorithm. Implementations that use a generic parser must

construct the entire A,band cmatrices each iteration and do not leverage the fact that the same optimization

problem is being solved repeatedly.

B. Performance Results

Prior to discussing the computational performance, we brieﬂy compare the real-time computed trajectory to

one that is (locally) optimal. The problem parameters used for this comparison are given in Table 3. We use

GPOPS-II to compute the locally optimal solution for comparison.82 Figure 5 shows the resulting trajectories

in the yI−zIlanding plane, alongside the thrust and torque trajectories. For the real-time solution, the circles

represent the last reference solution {¯xk}k∈Nobtained by the solve step prior to exiting the main iterative

loop, whereas the solid line corresponds to the continuous state trajectory obtained by integrating the solution

{¯uk,¯p}k∈Nthrough the nonlinear dynamics using (6). The attitude of the vehicle is depicted by the red lines in

Figure 5(a) at identical temporal points in each trajectory, and it can be seen to match well at each point. Both

the state and control trajectories show some key diﬀerences; namely the real-time control solution does not have

the minimum thrust arc seen in the solution computed by GPOPS-II and the torque solution follows a diﬀerent

albeit smoother trajectory. The torque jitter in the GPOPS-II solution is an artifact of that software’s known

diﬃculty in ﬁnding singular solutions when encompassed by non-singular arcs.82 These control diﬀerences do

not greatly impact the PTR algorithm’s ability to ﬁnd an acceptable sub-optimal solution, as the cost is not

signiﬁcantly aﬀected by the presence of the minimum thrust arc. As seen in Figure 6, the ﬁnal mass is very close

between the two trajectories. In fact, the real-time solution ﬁnds a solution that is roughly 0.6% sub-optimal

and with a ﬁnal time that is within 1.3% of the optimal solution. This sub-optimality is traded-oﬀ for the ability

to compute the solutions in real-time in an architecture that is appropriate for a ﬂight code implementation.

18 of 24

American Institute of Aeronautics and Astronautics

(a) The computed inertial position trajectories (b) The computed control trajectories

Figure 5: The real-time solution using N= 20 compared to the (locally) optimal planar landing solution. In

(a), the circles represent solution nodes at each k∈Nand the vehicle attitude is shown for both solutions at the

same time instances.

We now study the computational performance obtained by the real-time PTR algorithm in addition to the

sensitivity of key outputs to user-deﬁned algorithm parameters. The solution method was implemented in C++

an run using a single 3.2 GHz Intel i5 processor with 8GB of RAM. All code was compiled using the -O3 ﬂag.

Figure 7 shows the computational times obtained as a function of the discretization density N. Each data point

represents the mean value of 100 trials using the speciﬁed value of Nand all other parameters as in Table 3c. The

error bars that are shown indicate one standard deviation. The contributions of the pre-parse, convexiﬁcation,

parse and solve steps are shown individually, in addition to the total solution time. The top plot in Figure 7

shows that the total solution time and the solver time per PTR iteration follow the same trend as Nincreases.

It is expected that the solver time is cubic in Nsince the BSOCP solver performs a Cholesky factorization each

time it is called to obtain the Newton search direction,32 a function whose operation count scales with the

cube of the matrix dimension.81 The cubic polynomial ﬁt to the total time (shown by the red line) supports

the hypothesis that the total solution time is dominated by the internal operations of the BSOCP solver, and in

particular the Cholesky factorization. The time spent outside the solver consumes on average 2% of the total

solution time. The desirable conclusion is that the PTR algorithm adds little computational overhead to what is

needed by the solver. However, caution should be used when extrapolating this result to other problem instances,

as the ratio of time spent in the solver to time spent in other functions can vary between diﬀerent problems and

implementations.

The bottom four plots in Figure 7 show that the percent sub-optimality is roughly consistent across all tested

values of N, and that the computation time of the pre-parse, convexiﬁcation and parse steps scale linearly with

N. For the convexiﬁcation step, this is expected based on the computational complexity discussion presented

in §II.C. Both the pre-parse and parsing steps can be done very quickly, and do not impact the overall solution

time of the PTR algorithm.

Lastly, Figure 8 shows the variation in the ﬁnal time, the ﬁnal mass (i.e., the cost) and the total solution time

versus several parameters that are selected by the user. For each plot, all nominal values given in Table 3 were

held constant (with N= 15) and only the variable shown on the x-axis was changed. The ﬁnal time guess is

seen to strongly factor into the total solution time, and a minimum is observed around the optimal value of ≈9s,

as expected. As previously mentioned, the ﬁnal time guesses that are much shorter than the optimal one lead

to higher solution times compared to those that are longer. The values chosen for the virtual control and trust

region weights can aﬀect the dependent variables tested if they are chosen improperly; the results suggest there

is a rather large range for each parameter where the computed solution remains nearly the same. The solution

using wtr = 10−3produced results that did not converge and are marked with a red ×(the total solve time is

oﬀ of the chart). This unsurprisingly indicates that if state and control deviations are not penalized enough,

cSince the results shown are on a per iteration basis, we hypothesize that varying the initial conditions in a more traditional Monte

Carlo test would not change the results as presented. There are no additional constraints to activate and no additional non-zero

entries in Aor bto make the problem more challenging to solve.

19 of 24

American Institute of Aeronautics and Astronautics

(a) Translational states (b) Rotational states

Figure 6: Individual state tra jectories for the planar landing case study. The real-time results use N= 20.

the algorithm can step far enough from the reference trajectory that the linearizations are no longer valid, and

convergence suﬀers accordingly. The variations observed for the solution that uses wvc = 103are due to scaling

issues that start to arise when this parameter is too large.

The fourth row of Figure 8 shows that the values of the inertia and speciﬁc impulse can aﬀect the total solution

time, but do not strongly aﬀect the ﬁnal time or mass for this case study. This implies that algorithm parameters

tuned for nominal values do not need to be changed if the actual values change by up to +10

/−20%. Beyond this

range, the algorithm parameters may need to be changed slightly to obtain the best computational performance.

The increased solution time for large Isp is caused by the increasing optimal ﬁnal time that eventually requires

an additional PTR iteration to converge to. Caution must be exercised when extrapolating these latter two

results to other problem instances, since diﬀerent dynamics, boundary conditions and/or constraints can change

the relationship between J, Isp and the dependent variables studied here. A similar sensitivity analysis should be

carried out for each new implementation. Lastly, the ﬁfth row of Figure 8 shows the eﬀect of varying min (32).

While the ﬁnal mass and ﬁnal time are largely unaﬀected, it can be seen that lower values of mproduce faster

convergence. The optimal choice in this case is m= 1, the nominal value that is used.

IV. Conclusions

Solving challenging non-convex optimization problems in real-time on-board spacecraft has been identiﬁed as

a key technology required for future entry, descent and landing systems. In this paper, we have presented

a methodology for designing real-time algorithms that can be implemented in adherence to the standards of

spaceﬂight code. A set of general algorithmic steps were presented, followed by a case study to illustrate how

these steps are applied to a powered descent guidance problem. The planar landing problem that was studied

constitutes the most general landing problem with both rotational and translational states for which the optimal

control structure is theoretically understood. The case study indicates that solutions that are less than 1% sub-

optimal can be computed on the order of 100 ms using a 3.2 GHz Intel i5 processor with 8 GB of RAM. While

these results are speciﬁc to the planar landing problem that was studied, they oﬀer a promising indication that

the algorithm and methodology are suitable for the full scale 6-DoF problem.

Acknowledgements

This research has been supported by NASA grant NNX17AH02A and government sponsorship is acknowledged.

This paper is dedicated to the memory of John Alexander Hansuld.

20 of 24

American Institute of Aeronautics and Astronautics

Figure 7: The computational times and percent sub-optmality obtained for each primary step in the algorithm

versus the discretization density Nfor the planar landing case study.

References

1J. W. Jones, “The Recent Large Reduction in Space Launch Cost,” in 48th International Conference on Environmental Systems,

(Albuquerque, NM), 2018.

2R. T. Vought, “Commerce, Justice, Science, and Related Agencies Appropriations Act, 2020.” Executive Oﬃce of the President,

Oﬃce of Management and Budget, 2019.

3A. R. Klumpp, Apollo Lunar-Descent Guidance. Charles Stark Draper Laboratory, 1971.

4J. M. Carson III, M. M. Munk, R. R. Sostaric, J. N. Estes, F. Amza jerdian, J. B. Blair, D. K. Rutishauser, C. I. Restrepo,

A. Dwyer-Cianciolo, G. T. Chen, and T. Tse, “The SPLICE Project: Continuing NASA Development of GN&C Technologies for

Safe and Precise Landing,” in AIAA SciTech Forum, (San Diego, CA), 2019.

5E. A. Robertson, “Synopsis of Precision Landing and Hazard Avoidance (PL&HA) Capabilities for Space Exploration,” in AIAA

Guidance, Navigation, and Control Conference, American Institute of Aeronautics and Astronautics, 2017.

6E. S. Team, “Europa Study 2012 Report: Europa Lander Mission,” Tech. Rep. Task Order NMO711062 Outer Planets Flagship

Mission, Jet Propulsion Laboratory, 2012.

7A. M. Dwyer-Cianciolo, C. D. Karlgaard, D. Woﬃnden, R. A. Lugo, J. Tynis, R. R. Sostaric, S. Striepe, R. Powell, and J. M.

Carson, “Deﬁning Navigation Requirements for Future Missions,” in AIAA Scitech 2019 Forum, American Institute of Aeronautics

and Astronautics, 2019.

8NASA Science, “Moon’s South Pole in NASA’s Landing Sites.” https://solarsystem.nasa.gov/news/907/moons-south-pole-in-

nasas-landing-sites/, 2019. Accessed: 11/26/2019.

9M. Robinson, “Lunar Reconnaissance Orbiter Camera (LROC).” http://lroc.sese.asu.edu/posts/993, 2018. Accessed:

11/26/2019.

10J. S. Meditch, “On the Problem of Optimal Thrust Programming For a Lunar Soft Landing,” IEEE Transactions on Automatic

Control, vol. 9, no. 4, pp. 477–484, 1964.

11D. Lawden, “Optimal Trajectories for Space Navigation,” in Optimal Trajectories for Space Navigation, London: Butterworths,

1963.

12J.-P. Marec, Optimal Space Trajectories. Amsterdam: Elsevier Scientiﬁc Publishing Company, 1979.

13C. N. D’Souza, “An Optimal Guidance Law for Planetary Landing,” in AIAA Guidance, Navigation, and Control Conference,

(New Orleans, LA), 1997.

14U. Topcu, J. Casoliva, and K. D. Mease, “Fuel Eﬃcient Powered Descent Guidance for Mars Landing,” in AIAA Guidance,

Navigation, and Control Conference, (San Francisco, CA), 2005.

21 of 24

American Institute of Aeronautics and Astronautics

15U. Topcu, J. Casoliva, and K. D. Mease, “Minimum-Fuel Powered Descent for Mars Pinpoint Landing,” Journal of Spacecraft

and Rockets, vol. 44, no. 2, pp. 324–331, 2007.

16P. Lu, S. Forbes, and M. Baldwin, “A Versatile Powered Guidance Algorithm,” in AIAA Guidance, Navigation ,and Control

Conference, (Minneapolis, MN), 2012.

17P. Lu, “Propellant-Optimal Powered Descent Guidance,” Journal of Guidance, Control, and Dynamics, vol. 41, no. 4, pp. 813–

826, 2018.

18J. Nocedal and S. J. Wright, Numerical Optimization. New York, NY: Springer Science & Business Media, 2006.

19A. Forsgren, P. E. Gill, and M. H. Wright, “Interior Methods for Nonlinear Optimization,” SIAM Review, vol. 44, no. 4,

pp. 525–597, 2002.

20S. Boyd and L. Vandenberghe, Convex Optimization. Cambridge, UK: Cambridge University Press, 2004.

21B. A¸cıkme¸se and S. Ploen, “Convex Programming Approach to Powered Descent Guidance for Mars Landing,” Journal of

Guidance, Control, and Dynamics, vol. 30, no. 5, pp. 1353–1366, 2007.

22B. A¸cıkme¸se and L. Blackmore, “Lossless Convexiﬁcation of a Class of Optimal Control Problems with Non-Convex Control

Constraints,” Automatica, vol. 47, no. 2, pp. 341–347, 2011.

23L. Blackmore, B. A¸cıkme¸se, and D. P. Scharf, “Minimum-Landing-Error Powered-Descent Guidance for Mars Landing Using

Convex Optimization,” Journal of Guidance, Control, and Dynamics, vol. 33, no. 4, pp. 1161–1171, 2010.

24J. M. Carson III, B. A¸cıkme¸se, and L. Blackmore, “Lossless Convexiﬁcation of Powered-Descent Guidance with Non-Convex

Thrust Bound and Pointing Constraints,” in IEEE American Control Conference, (San Francisco, CA), 2011.

25B. A¸cıkme¸se, J. M. Carson III, and L. Blackmore, “Lossless Convexiﬁcation of Nonconvex Control Bound and Pointing Constraints

of the Soft Landing Optimal Control Problem,” IEEE Transactions on Control Systems Technology, vol. 21, no. 6, pp. 2104–2113,

2013.

26M. W. Harris and B. A¸cıkme¸se, “Lossless convexiﬁcation for a class of optimal control problems with linear state constraints,”

in 52nd IEEE Conference on Decision and Control, IEEE, 2013.

27M. W. Harris and B. A¸cıkme¸se, “Lossless convexiﬁcation for a class of optimal control problems with quadratic state constraints,”

in 2013 American Control Conference, IEEE, 2013.

28M. W. Harris and B. A¸cıkme¸se, “Lossless Convexiﬁcation of Non-Convex Optimal Control Problems for State Constrained Linear

Systems,” Automatica, vol. 50, no. 9, pp. 2304–2311, 2014.

29L. Blackmore, B. A¸cıkme¸se, and J. M. Carson III, “Lossless Convexiﬁcation of Control Constraints for a Class of Nonlinear

Optimal Control Problems,” Systems and Control Letters, vol. 61, no. 8, pp. 863–870, 2012.

30D. Malyuta and B. Acikmese, “Lossless Convexiﬁcation of Optimal Control Problems with Semi-Continuous Inputs,” arXiv

e-prints, p. arXiv:1911.09013, 2019.

31D. Malyuta, M. Szmuk, and B. Acikmese, “Lossless Convexiﬁcation of Non-Convex Optimal Control Problems with Disjoint

Semi-Continuous Inputs,” arXiv e-prints, p. arXiv:1902.02726, 2019.

32D. Dueri, J. Zhang, and B. A¸cıkme¸se, “Automated Custom Code Generation for Embedded, Real-time Second Order Cone

Programming,” IFAC Proceedings Volumes, vol. 47, no. 3, pp. 1605–1612, 2014.

33D. Dueri, B. A¸cıkme¸se, D. P. Scharf, and M. W. Harris, “Customized Real-Time Interior-Point Methods for Onboard Powered-

Descent Guidance,” Journal of Guidance, Control, and Dynamics, vol. 40, no. 2, pp. 197–212, 2016.

34A. Domahidi, E. Chu, and S. Boyd, “ECOS: An SOCP Solver for Embedded Systems,” in European Control Conference,

pp. 3071–3076, 2013.

35D. Dueri, B. A¸cıkme¸se, M. Baldwin, and R. S. Erwin, “Finite-Horizon Controllability and Reachability for Deterministic and

Stochastic Linear Control Systems with Convex Constraints,” in IEEE American Control Conference, 2014.

36U. Eren, D. Dueri, and B. A¸cıkme¸se, “Constrained Reachability and Controllability Sets for Planetary Precision Landing via

Convex Optimization,” Journal of Guidance, Control, and Dynamics, vol. 38, no. 11, pp. 2067–2083, 2015.

37D. Dueri, S. V. Rakovic, and B. Acikmese, “Consistently Improving Approximations for Constrained Controllability and Reach-

ability,” in 2016 European Control Conference (ECC), IEEE, 2016.

38M. Szmuk, B. A¸cıkme¸se, and A. W. Berning, “Successive Convexiﬁcation for Fuel-Optimal Powered Landing with Aerodynamic

Drag and Non-Convex Constraints,” in AIAA Guidance, Navigation, and Control Conference, (San Diego, CA), 2016.

39M. Szmuk, T. P. Reynolds, and B. A¸cıkme¸se, “Successive Convexiﬁcation for Real-Time 6-DoF Powered Descent Guidance with

State-Triggered Constraints,” arXiv e-prints, 2018. arXiv:1811.10803.

40M. Szmuk, T. P. Reynolds, B. A¸cıkme¸se, M. Mesbahi, and J. M. Carson III, “Successive Convexiﬁcation for Real-Time Rocket

Landing Guidance with Compound State-Triggered Constraints,” in AIAA SciTech Forum, (San Diego, CA), 2019.

41T. P. Reynolds, M. Szmuk, D. Malyuta, M. Mesbahi, B. A¸cıkme¸se, and J. M. Carson III, “A State-Triggered Line of Sight

Constraint for 6-DoF Powered Descent Guidance Problems,” in AIAA SciTech Forum, (San Diego, CA), 2019.

42T. P. Reynolds, M. Szmuk, D. Malyuta, M. Mesbahi, B. A¸cıkme¸se, and J. M. Carson III, “Dual Quaternion Based 6-DoF Powered

Descent Guidance with State-Triggered Constraints,” arXiv e-prints, 2019. arXiv:1904.09248.

43Y. Mao, M. Szmuk, and B. A¸cıkme¸se, “Successive Convexiﬁcation of Non-Convex Optimal Control Problems and its Convergence

Properties,” in IEEE Conference on Decision and Control, (Las Vegas, NV), 2016.

44Y. Mao, D. Dueri, M. Szmuk, and B. A¸cıkme¸se, “Successive Convexiﬁcation of Non-Convex Optimal Control Problems with

State Constraints,” IFAC-PapersOnLine, vol. 50, no. 1, pp. 4063–4069, 2017.

45Y. Mao, M. Szmuk, and B. A¸cıkme¸se, “Successive Convexiﬁcation: A Superlinearly Convergent Algorithm for Non-convex

Optimal Control Problems,” arXiv e-prints, 2018. arXiv:1804.06539.

46J. Schulman, Y. Duan, J. Ho, A. Lee, I. Awwal, H. Bradlow, J. Pan, S. Patil, K. Goldberg, and P. Abbeel, “Motion Planning

with Sequential Convex Optimization and Convex Collision Checking,” The International Journal of Robotics Research, vol. 33,

no. 9, pp. 1251–1270, 2014.

47R. Bonalli, A. Cauligi, A. Bylard, and M. Pavone, “GuSTO: Guaranteed Sequential Trajectory Optimization via Sequential

Convex Programming,” in 2019 IEEE International Conference on Robotics and Automation (ICRA), IEEE, 2019.

48R. Bonalli, A. Bylard, A. Cauligi, T. Lew, and M. Pavone, “Trajectory Optimization on Manifolds: A Theoretically-Guaranteed

Embedded Sequential Convex Programming Approach,” in Robotics: Science and Systems, 2019.

49T. A. Howell, B. E. Jackson, and Z. Manchester, “ALTRO: A Fast Solver for Constrained Trajectory Optimization,” in IEEE/RSJ

International Conference on Intelligent Robots and Systems, 2019.

22 of 24

American Institute of Aeronautics and Astronautics

50X. Liu and P. Lu, “Solving Nonconvex Optimal Control Problems by Convex Optimization,” Journal of Guidance, Control, and

Dynamics, vol. 37, no. 3, pp. 750–765, 2014.

51X. Liu, Z. Shen, and P. Lu, “Solving the Maximum-Crossrange Problem via Successive Second-Order Cone Programming With

a Line Search,” Aerospace Science and Technology, vol. 47, pp. 10–20, 2015.

52X. Liu, Z. Shen, and P. Lu, “Entry Trajectory Optimization by Second-Order Cone Programming,” Journal of Guidance, Control,

and Dynamics, vol. 39, no. 2, pp. 227–241, 2016.

53Z. Wang and M. J. Grant, “Constrained Trajectory Optimization for Planetary Entry via Sequential Convex Programming,” in

AIAA Atmospheric Flight Mechanics Conference, American Institute of Aeronautics and Astronautics, 2016.

54Z. Wang and M. J. Grant, “Improved Sequential Convex Programming Algorithms for Entry Trajectory Optimization,” in AIAA

Scitech 2019 Forum, American Institute of Aeronautics and Astronautics, 2019.

55M. Szmuk, C. A. Pascucci, D. Dueri, and B. Acikmese, “Convexiﬁcation and Real-Time On-board Optimization for Agile Quad-

Rotor Maneuvering and Obstacle Avoidance,” in 2017 IEEE/RSJ International Conference on Intelligent Robots and Systems

(IROS), IEEE, 2017.

56M. Szmuk, C. A. Pascucci, and B. Acikmese, “Real-Time Quad-Rotor Path Planning for Mobile Obstacle Avoidance Using

Convex Optimization,” in 2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), IEEE, 2018.

57M. Szmuk, D. Malyuta, T. P. Reynolds, M. S. Mceowen, and B. A¸cıkme¸se, “Real-Time Quad-Rotor Path Planning Using

Convex Optimization and Compound State-Triggered Constraints,” in IEEE/RSJ International Conference on Intelligent Robots

and Systems, p. arXiv:1902.09149, IEEE, 2019.

58Y. Mao, M. Szmuk, and B. Acikmese, “A Tutorial on Real-time Convex Optimization Based Guidance and Control for Aerospace

Applications,” in 2018 Annual American Control Conference (ACC), IEEE, 2018.

59D. Malyuta, T. Reynolds, M. Szmuk, M. Mesbahi, B. Acikmese, and J. M. Carson, “Discretization Performance and Accuracy

Analysis for the Rocket Powered Descent Guidance Problem,” in AIAA Scitech 2019 Forum, American Institute of Aeronautics and

Astronautics, 2019.

60B. A¸cıkme¸se, M. Aung, J. Casoliva, S. Mohan, A. Johnson, Scharf, M. D., S. D., A. Wolf, and M. Regehr, “Flight Testing of

Trajectories Computed by G-FOLD: Fuel Optimal Large Divert Guidance Algorithm for Planetary Landing,” in 23rd AAS/AIAA

Space Flight Mechanics Meeting, Kauai, HI, 2013, AAS/AIAA, 2017.

61D. P. Scharf, M. W. Regehr, G. M. Vaughan, J. Benito, H. Ansari, M. Aung, A. Johnson, J. Casoliva, S. Mohan, D. Dueri,

B. Acikmese, D. Masten, and S. Nietfeld, “ADAPT Demonstrations of Onboard Large-Divert Guidance with a VTVL Rocket,” in

2014 IEEE Aerospace Conference, IEEE, 2014.

62JPL and M. S. Systems, “750 Meter Divert Xombie Test Flight for G-FOLD, Guidance for Fuel Optimal Large Divert, Validation,”

http://www.youtube.com/watch?v=jl6pw2oossU, 2012.

63JPL and M. S. Systems, “500 meter divert Xombie test ﬂight for G-FOLD, Guidance for Fuel Optimal Large Divert, validation,”

http://www.youtube.com/watch?v=1GRwimo1AwY, 2012.

64D. Dueri, Real-time Optimization in Aerospace Systems. Ph.D., University of Washington, 2018.

65J. Mattingley and S. Boyd, “CVXGEN: A Code Generator for Embedded Convex Optimization,” Optimization and Engineering,

vol. 13, no. 1, pp. 1–27, 2011.

66A. Zanelli, A. Domahidi, J. Jerez, and M. Morari, “FORCES NLP: An Eﬃcient Implementation of Interior-Point Methods for

Multistage Nonlinear Nonconvex Programs,” International Journal of Control, pp. 1–17, 2017.

67A. Domahidi, A. U. Zgraggen, M. N. Zeilinger, M. Morari, and C. N. Jones, “Eﬃcient Interior Point Methods for Multistage

Problems Arising in Receding Horizon Control,” in 2012 IEEE 51st IEEE Conference on Decision and Control (CDC), IEEE, 2012.

68A. Domahidi, Methods and Tools for Embedded Optimization and Control. PhD thesis, ETH Zurich, 2013. Diss., Eidgen¨ossische

Technische Hochschule ETH Z¨urich, Nr. 21366, 2013.

69S. Mariethoz, A. Domahidi, and M. Morari, “High-Bandwidth Explicit Model Predictive Control of Electrical Drives,” IEEE

Transactions on Industry Applications, vol. 48, no. 6, pp. 1980–1992, 2012.

70J. L. Jerez, P. J. Goulart, S. Richter, G. A. Constantinides, E. C. Kerrigan, and M. Morari, “Embedded Predictive Control on

an FPGA using the Fast Gradient Method,” in 2013 European Control Conference (ECC), IEEE, 2013.

71A. Liniger, A. Domahidi, and M. Morari, “Optimization-Based Autonomous Racing of 1:43 Scale RC Cars,” arXiv e-prints,

p. arXiv:1711.07300, 2017.

72J. Kabzan, L. Hewing, A. Liniger, and M. N. Zeilinger, “Learning-Based Model Predictive Control for Autonomous Racing,”

IEEE Robotics and Automation Letters, vol. 4, no. 4, pp. 3363–3370, 2019.

73U. Lee and M. Mesbahi, “Constrained Autonomous Precision Landing via Dual Quaternions and Model Predictive Control,”

Journal of Guidance, Control, and Dynamics, vol. 40, no. 2, pp. 292–308, 2017.

74G. J. Holzmann, “The Power of Ten – Rules for Developing Safety Critical Code,” IEEE Computer, 2006.

https://spinroot.com/p10/.

75T. P. Reynolds and M. Mesbahi, “Optimal Planar Powered Descent with Independent Thrust and Torque,” Journal of Guidance,

Control, and Dynamics (Submitted), 2019.

76L. D. Berkovitz, Optimal Control Theory. New York, NY: Springer-Verlag, 1974.

77D. P. Scharf, B. A¸cıkme¸se, D. Dueri, J. Benito, and J. Casoliva, “Implementation and Experimental Demonstration of Onboard

Powered-Descent Guidance,” Journal of Guidance, Control, and Dynamics, vol. 40, no. 2, pp. 213–229, 2017.

78M. I. Ross, Q. Gong, M. Karpenko, and R. J. Proulx, “Scaling and Balancing for High-Performance Computation of Optimal

Controls,” Journal of Guidance, Control, and Dynamics, vol. 41, no. 10, pp. 2086–2097, 2018.

79J. T. Betts, Practical Methods for Optimal Control Using Nonlinear Programming. Philadelphia, PA: SIAM, 2001.

80P. E. Gill, W. Murray, and M. H. Wright, Practical Optimization. Academic Press, Inc., 1981.

81L. N. Trefethen and D. Bau, Numerical Linear Algebra. Philadelphia, PA: SIAM, 1997.

82M. A. Patterson and A. V. Rao, “GPOPS-II: A MATLAB Software for Solving Multiple-Phase Optimal Control Problems Using

hp-Adaptive Gaussian Quadrature Collocation Methods and Sparse Nonlinear Programming,” ACM Transactions on Mathematical

Software, vol. 41, no. 1, pp. 1–37, 2014.

23 of 24

American Institute of Aeronautics and Astronautics