Planetary Trajectory Design Using Generative AI Tools

Developing planetary trajectories involves massive trade studies over large spans of launch dates, propulsion systems, gravity assist bodies, launch vehicles, etc. Such work requires rapid computation and optimization of many thousands of trajectories to characterize the solution space. This work requires regular development of in-house software (primarily the Evolutionary Mission Trajectory Generator, EMTG) to solve new types of problems often introduced by each new project. Working in this highly-coupled workflow of physics, engineering/design, optimization, and software development, pushes trajectory designers outside their areas of expertise—particularly for software development—costing valuable time that can hold up entire projects.

The overall objectives of this work are to integrate Large-Language Models (LLMs) into the end-to-end workflow for planetary trajectory design (at least, the workflow as it is done at NASA-GSFC) and identify the most effective ways to leverage LLMs in that process. Both closed-source and open-source LLMs will be considered. This work is done in collaboration with NASA’s Chief Artificial Intelligence Office and uses approved cloud-computing services to access a variety of LLM models, including GPT-4o, Llama 3.2, and Claude 3.5).

The key objectives of this work are as follows:

1) Assistant Setup

The LLM needs to be informed of our in-house documents, software, and data in order to help users with any queries related to our design process. With existing context-window limits, most LLMs (at the time of writing this description) are not able to ingest an entire repository of files by attaching them to a prompt. As such, our in-house files will first be processed and vectorized for retrieval-augmented generation (RAG), which will allow the LLMs to conduct quick context-based searches of our repository documents, code and data when responding to user queries. The goal of the RAG setup is to have the LLM behave as if it did have all of our files in its context window or was otherwise trained on them.

With the LLM informed of our files, it can be tested with various prompts to determine its ability to respond to various user queries. Some specific queries to be tested will include: installing our in-house software, setting up and running our software, how the software works and what models it’s using. In this objective and all others, various prompts will be investigated with those found to be most effective documented for future users. Queries regarding the code will be a larger area of focus as described in the next objective.

2) Code Development

The LLM’s knowledge of our software will be evaluated by checking its responses to questions pertaining to the code base (e.g. class structure, functions, trajectory models, etc.). The LLMs ability to write new code for our software will also be investigated, from small tweaks of existing code to large additions of new code. The evaluation of code quality will include executability, validation of function, readability (e.g. organization, simplicity, commenting, etc.), and whether any debugging was required. The expected time saved as a result of using an LLM to assist in code writing in this manor is on the order of weeks to months.

3) Data Analysis

Process trajectory data with LLMs and generate various data products, such as a 3-D visualization of the trajectory in various coordinate frames, a csv file of specified trajectory characteristics, scatter plots, and other graphics and/or animations.

To help mitigate any errors or “hallucinations” created by the LLM, it will be instructed to create Python scripts to generate such products, rather than to generate the data products directly, so that the code can be evaluated for accuracy and ensure that the LLM is not fabricating or otherwise misrepresenting data. This overlaps with Objective 2 in that code writing is involved, but here, we’re working with more basic Python scripts rather than our in-house software’s source code. The nature of the requests for the LLM for these visualization scripts will also differ from Objective 2.

In the case of ephemeris data, specialized data formats will be considered, such as “SPK” files, which are commonly used but require programs and/or code packages to parse. If unable to process directly, the LLM can interface with the ephemeris data via the Python package SpiceyPy which uses the NASA-JPL SPICE Toolkit.

We will also test the LLM’s ability to query our data for various beneficial characteristics, such as good observation opportunities for a particular instrument (which can be laborious to assess manually) or that have issues, such as solutions with low perihelion. Any such responses would need to be investigated and verified, but finding such solutions out of massive trajectory databases will save our team days or weeks of work. For some of these applications, a combination of asking the LLM for a direct solution followed by checking with a script is likely to be more efficient while still being able to verify the accuracy of the LLM’s response.

4) Trajectory Design

The ability of the LLM to provide a good initial guess for our trajectory optimization software, EMTG, will be investigated. EMTG designs and optimizes trajectories by conducting a stochastic global search with a gradient-based local-optimization. EMTG does not require an initial guess by the user to initiate the global search, but when not given an initial guess, a basic uniform random distribution is used to provide one. This works well for many problems, but when many gravity assists are required, the global search can take a long time to find a solution (potentially too long for the user to wait for it). By training a customized version of an LLM using archived EMTG input files with the provided optimal solution, the LLM can provide an initial guess. In the case of EMTG, the LLM only has to do better than a uniformly-distributed random initial guess, and we anticipate that it will do much better.

The AI assistant developed for this work will help current and future planetary trajectory designers in nearly all aspects of their workflow. For the existing experts in this area at GSFC, this will save many hours of one-on-one time to help newer users. Additionally, building an AI with such a comprehensive knowledge of our workflow will help to retain our highly specialized knowledge base and custom-built software for future employees.

More broadly, the implementation of this AI assistant includes many elements that will be beneficial to many engineers and scientists across NASA and elsewhere. Anyone who works with specialized data and code should benefit from this effort. Any scripts developed for this work for setting up the AI assistant will be made available, as well as any notable prompts or prompting techniques that are identified.

LLMs are already bringing about a major change in nearly every field of work. The models available today are the worst we'll ever use, and we haven't yet determined how best to use the models we have now. Despite the ongoing study and experimentation with LLMs, they have already been shown to provide enough benefit to many jobs to be adopted. As such, the integration of LLMs into future workflows seems inevitable. How to best adapt the roles of scientists and engineers in the presence of LLMs, and other implementations of AI, will be up to those scientists and engineers. This work will provide insight into what that new role may look like for planetary trajectory design and any other field of work with a similar or analogous workflow.

This is early/mid-stage (TRL 4) — the most realistic path in is NASA SBIR/STTR, which funds small businesses and research institutions to develop technology aligned with NASA's needs (equity-free, phased funding). Check whether a current SBIR/STTR solicitation topic overlaps with this project's technology area, or contact the project directly (above) to ask.

None of these are guaranteed paths for this specific project — TechPort itself doesn't have an "apply" button. Reaching out to the contact(s) above with a specific question is usually the fastest way to find out what's actually open.