Solving the problem Onboard.

For most of spaceflight, the trajectory was computed on the ground and uploaded. The spacecraft followed it. That works while the world matches the plan, and it fails the moment it does not: a target that has drifted, a thruster that underperforms, a landing site that turns out to be strewn with boulders.

Embedded optimisation replaces the stored trajectory with a problem statement. The vehicle carries the objective, the constraints and a solver, and works out what to do from where it actually is. The appeal is obvious. The difficulty is that a solver on a spacecraft has to return an answer every time, within a fixed budget, on a processor a laptop would embarrass.

Convexity. A convex problem has one minimum, and interior-point methods reach it in a predictable number of iterations. That predictability is the whole argument: you can state a worst-case solve time and defend it, which you cannot do for a general non-linear search.

Lossless convexification. Some genuinely non-convex constraints, such as a thruster that must fire between a minimum and a maximum or not at all, can be relaxed into convex ones in a way that provably does not change the answer. The relaxed problem’s optimum is the original problem’s optimum. This is what made powered-descent guidance solvable in real time.

Successive convexification. Where the problem cannot be made convex outright, it is linearised about a reference and solved repeatedly, each solution becoming the next reference, with a trust region to stop it wandering. Most practical descent and rendezvous guidance now works this way.

Code generation. A solver generated for one specific problem structure, with no dynamic memory allocation and no branching on data, can be certified in a way a general-purpose library cannot. Because the dimensions and the sparsity pattern are fixed when the code is generated, the memory footprint is known at compile time, the loop bounds are constant, and the linear algebra reduces to a fixed sequence of operations. What the reviewer gets is flat, readable source that can be checked against a coding standard line by line, rather than a templated library whose control flow depends on the data it is handed.

An optimiser that is usually fast is not a flight system. What makes it one is a bound you can defend to a reviewer: this problem, this processor, this many iterations, this worst case, and a defined answer for what happens if the problem turns out infeasible.

This is the area we work in directly. Our capabilities are here.